Given the dangers of SUID shell scripts, is there a more secure way of giving passwordless access to scripts (bash, PHP) with root permissions in Linux?
(Ubuntu 8.10)
+11
A:
You could consider sudo.
Although not 'passwordless', it doesn't require the user to be given the root password. It can also provide an audit trail of use of the script.
edit: as per comment from Chris, there is an option not to require a password at all for certain commands, see here for details. It can also be set up not to prompt excessively for the password, i.e. one entry of the password can be good for multiple commands over a period of use.
By the way, sudo is built in to Ubuntu and nicely integrated with Gnome. When ubuntu prompts you for your password to do privileged operations, that's sudo under the hood.
frankodwyer
2008-12-29 12:10:50
sudo can be configured to not ask for a password. I think it's called NOPASSWD, but read the sudoers manpage to be sure.
Chris Jester-Young
2008-12-29 12:12:43
This is dangerous! Don't do it! Read the article about security issues with suid root scripts; sudo doesn't solve any of these.
Kim
2008-12-29 12:35:52
True, a vulnerable script is still a vulnerable script. However sudo does allow you to limit who can run it in a granular way, and provides an audit trail.
frankodwyer
2008-12-29 13:18:48
I disagree strongly with Kim's "sudo doesn't solve any of these" - see my comment below.
Daniel Papasian
2009-05-06 13:02:42
+5
A:
I would recommend sudo. Be sure to tighten your sudoers file appropriately; and yes, you can allow some commands to be executed with no password being requested.
Chris Jester-Young
2008-12-29 12:11:20
Good point, however it is not quite true that it is no better. It limits the users who can run the script in a granular way, and provides an audit trail (granted, there are other ways to do that too).
frankodwyer
2008-12-29 13:08:14
It's not true that it "isn't any better" -- unless people were suggesting trying to start a shell script with #!/bin/sudo or some other crazy idea.There is a race condition with allowing suid-root shell script (programs that start with #!) execution, which is why exec() on modern systems ignores the suid-root bit for those files.Specifically, if a suid-root shell script exists anywhere on the computer, I can, in a directory I own/can write to, create a link to it, run it, and after /bin/sh starts but before it opens the file, move away the link and put my own file there.
Daniel Papasian
2009-05-06 12:57:55
And, in fact, if starting a shell script with #!/bin/sudo actually does work, it *could* be more secure because a sudoers configuration file could force users to run /bin/sudo /path/to/a/specific/link -- sudoers lets you restrict arguments, so this race condition could be avoided (/bin/sudo /path/to/malicious/link would be prohibited by sudoers)
Daniel Papasian
2009-05-06 13:02:07
+4
A:
Be sure to review the "PREVENTING SHELL ESCAPES" section of the sudoers man page if you go the sudo route.
calebgroom
2008-12-30 02:49:21
+1
A:
To improve security consider whether it is possible to do the operation as a special user or group, which has exactly the access rights needed for it. Then you can make the script setuid/setgid for that user or group.
starblue
2008-12-30 09:10:21
See my comment to Kim's post above - there is a race condition with allowing setuid on files that start with the magic #!
Daniel Papasian
2009-05-06 12:58:57
+1
A:
For a really heavy-weight solution, consider a MAC (Mandatory Access Control) system, like SELinux, AppArmor, TrustedBSD etc.
phjr
2008-12-30 14:59:02