a security work around if possible 1

[keak]

Hi there,

I have a slightly complicated security problem, I was wondering if anyone can point out some suggestions.

I have a JSP page running on Redhat that will execute a shell script. The shell script contains the following code:

#!/bin/sh
scp schedule.sh user1@differenthost:~/schedule.sh
ssh user1@differenthost <<END_SCRIPT
./schedule.sh $1 $2
exit
END_SCRIPT
exit 0

Basically what the code does is that it uploads a shell script to a different box and then ssh to that box to execute that shell script with some arguments. This code is currently owned by “user1” on my Redhat and is working just fine when evoked from the command line (I have setup private/public ssh keys between user1 and differenthost with no password required, so that I don’t have to hardcode the pw).

My problem is, when this code is invoked from JSP, I get a permission denied error. I finally found out the reason for this and it was because JSP is running as the “Apache” user and it has no right to ssh to differenthost. A direct workaround will be to have this shell owned by the “Apache” user and setup a public/private key for “Apache”, but this will create a big security risk.

I was wondering if someone can point out any suggestions how I should go about setting the permission for my scenario.

Thanks,

 

[TrojanWarBlade]

This sounds to me like it's begging for security problems.
Your JSP will run, as you rightly point out, as Apache and consequently anything you try to run from it will have those permissions.
You could, I guess, write a little client / server system where your JSP simply connects to a process that runs as the appropriate user and passes the parameters across to that program. The server program could then exeucte your scp and ssh with lower risks but it would still, in principle, allow anyone with web access to trigger a call.
There are many ways to do a little client server kind of thing like that and you would not necessarily have to use sockets but I still think this is a security hole waiting to be breached.


Trojan.

 

[Annihilannic]

Personally I don't think it presents too much risk if you allow the apache user to SSH specifically to 'differenthost' as user1 (i.e. don't use that pair of public and private keys anywhere else) and run the commands. Also make sure there is no copy of the public key on the local host. Ensure that user1's access is sufficiently restricted on the remote host. If someone figures out how to run commands through your web server you're pretty much compromised already, so I don't think having SSH access to another host as a basic user is adding much more risk to the scenario.

Annihilannic.

 

[columb]

I'm a big fan of Sudo as a solution to security problems. If the sudoers file is set up correctly then 'apache' can run the transfer script as user1 and nothing else. The sudoers entry will look like

apache thisserver = /usr/bin/su - user1 -c  /home/user1/tx.sh

I use something very similar to get round allowing certain groups of users to use ssh/sftp for certain commands without opening the whole can of worms

Columb Healy

 

[TrojanWarBlade]

The problem is that running a shell script is effectively kicking off a shell and therefore has risks.
Granted the user would be limited to the permissions associated with Apache but I for one would still prefer not to risk giving the whole world browser access with no security to a logged in shell on my machine regardless of which userid it was.



Trojan.

 

[keak]

Thank you all for the inputs. I think sudo may sound like an option that I may want to look into.
The immediate approach I took was to have the Apache user (from JSP pag) write the shell script command into a text file, and have a contab (as User1) run every couple minutes to check this file to see if there has been any new requirests for remote SCP schedules.

However, this method I think is still a pretty big security risk and memory intensive (since the cron has to run on a short interval) and the approach that columb suggested sounds like the best work-around to the problem I had.


Thanks,