On Tue, Feb 15, 2005 at 04:35:16PM -0600, Mark wrote: | running scripts with the suid bit set is a security hole.
If you're going to make a claim like this, you'll need to explicitly define what a `script' is. If it's `a text file, marked as executable, that starts with a #!/path/to/interpeter', then yes, you're somewhat correct in that this can be dangerous to allow. In the past, many *nix OSs have not allowed it, or allowed it but it opens serious security holes when uses. However, most modern *nixes do permit it, and have closed the OS-related security holes. | It shouldn't be allowed (by design). I'm not sure if there is a | kernel option to allow it. IMHO, it's a bug if it does. No, done properly it can be safe, if the OS does it's part right too. This applies to any setuid program, of course. Modern linuxes do allow it, and do it correctly. Making a setuid root /bin/sh script is probably not a good idea. But making a setuid root perl script is probably not a bad idea at all (as long as you know what you're doing) -- perl then switches into taint mode, and won't accept any user input until it's been `cleaned' by the program. (Of course, you can create routines to clean data that are ineffective, but perl can't always protect you from yourself.) You mentioned python -- it wouldn't surprise me if it has the same functionality, though I'm not familiar with it's specifics. | Limiting the user to sudo the single script should be ok as long as they | cannot modify the script, the path to the interpreter (bash, perl, | whatever) is literal (no env, or ~/ etc), and the interpreter and any | libraries that it can pull in are not writable or modifiable to the user. | You have to look out for other things though. For example, for python | scripts, one can change the PYTHONPATH environment vars to pull in user | rougue libs, instead of libs elsewhere on the system. I also wonder | whether, as a regular user, it is possible to sudo, chroot, then run | the script to call some other program as the interpreter. Things like sudo generally clean the environment so that this cannot be taken advantage of. If you make your own setuid program or wrapper, cleaning the environment (or wiping it out entirely) is usually the very first thing you do. Also, only root can run chroot(), so what you've described isn't an option if you want to use it to hack root. (And what you've described is exactly why chroot() can only be used by root.) | There has to be some level of trust when allowing sudo. You basically | guard against the accident, but it is very hard to guard against the | intentional. Yes, you need to be careful about what you're doing. sudo protects you as much as it can, but it can't do everything. For example, if you use sudo to give root access to a program that starts an editor, many editors allow you to start a shell. Bam, root. Or you can open another file -- so you open /etc/passwd or /etc/shadow, add a new account -- bam, root. You need to be careful. -- Doug McLaren, [EMAIL PROTECTED] COFFEE.EXE missing - Insert cup and press any key. _______________________________________________ Siglinux mailing list [email protected] http://www.utacm.org:81/mailman/listinfo/siglinux
