Hi Wayne, Hope you and the family are doing well. Kick them kids for me ;) Got any Plan 9 boxes running yet? Exactly, what I was interested in though was are there any situations or programs that one can run using #2 that one can't do using #1. It isn't an issue of security or user rights per se but rather a 'shell compatibility' issue. Is there an aspect of *nix that allows programs to be loaded directly, while they won't run via a shell? Is that clear as mud or what? I believe the first is slightly safer because you could wrap shell (eg put it in another dir and use a script in /bin/sh's place). The reason I believe it is more secure (but only very!!! slightly) is that before we can execute the users target code they -must- execute 'sh' which provides an opportunity for doing something about stopping them. It's an interesting mind game if nothing else. We should do a 1st Saturday sometime this summer ;) On Fri, 9 May 2003, Wayne Walker wrote:

sudo is actually almost never secure. As you imply, with line 1 bob can do _anything_ just like line 2.

Here are some more less obvious examples where bob can do _anything_

1. bob pine 2. bob vi 3. bob chown 4. bob chmod

With any of the 4 above, bob can do anything.

With 1 or 2, bob can run any command from within the program (! is allowed in vi, and if you set $EDITOR to vi before running pine...)

In 3 and 4, bob can make setuid programs or change perms on /etc and put his own passwd/shadow files in place.

Bottom line, if you give someone sudo access you should tgrust them to be root, OR you should only allow them to run very specific _scripts/binaries_ that you wrote for them specifically (e.g. chown_files_to_others_in_his_primary_group, restart_lpd, restart_httpd...) And here you still have to be careful about these programs....

On Thu, May 08, 2003 at 09:34:15PM -0500, Jim Choate wrote:

...

Given a basic Linux (or *nix) system with a user bob. Assume that bob has sudo capability. There are two approaches (I'm not going to use exact syntax):

1. bob sh

2. bob All

So, in the first case bob can: sudo sh -c "foo"

and in the second bob can: sudo foo

Why would the first approach represent a more secure mechanism?

It is true that sh could be a wrapper or have sticky bits, etc. We'll assume these are not an issue. The point being why is running a program directly as root in this manner less secure than running the program through a shell as root?

Example? Explanation?

Thanks.

-- ____________________________________________________________________ We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, "Plan 9 from Outer Space" ravage@ssz.com jchoate@open-forge.org www.ssz.com www.open-forge.org --------------------------------------------------------------------

On Sat, 10 May 2003, Thomas Shaddack wrote:

For a limited set of specific tasks, there is a workaround. Have a directory to which the user has write access, have a script run every minute or every 5 minutes or so from crontab that checks if there is a file with specified name there, and if so, do an action and erase the file.

I solved the problem when one of our programmers needed to occassionally restart Apache to which he did not have the rights. Instead of messing with sudo and taking the risk, he now just has to do "touch /var/cmd/apacherestart" and in next couple minutes it gets done.

This trick can be used even for passing commands, which then can be put into the file (echo "commands" > /var/cmd/whatevercommandfile) and the script then reads them from there (and checks the syntactical validity of the arguments to prevent eventual attack through this route).

I've used that sort of approach as well. With regard to the sh wrapper I mentioned earlier, I like chroot for that sort of stuff. One approach is that when the user executes the sh -c the sh wrapper creates a well know chroot sequence and perhaps copies information from the live file system into the chroot jail. Let's the user makes modes, and when the "foo" command quits the script can then evaluate the results (for example greping for changes to itself in all files in the chroot jail. Assuming it looks ok it can cp the changes back to the live filesystem and away you go.

Should be bulletproof.

I -never- make that claim ;) -- ____________________________________________________________________ We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, "Plan 9 from Outer Space" ravage@ssz.com jchoate@open-forge.org www.ssz.com www.open-forge.org --------------------------------------------------------------------