W. Wayne Liauh wrote:
Hi Vince-Apparently you have never used xcdroast or grip yourself? What is the most recent version of "commercial" Linux distribution that you have used?I am asking this question, because you apparently don't really know the heck of what I was talking about. Yes, there are some inherent problems with the setuid facility--anything that deals with root privilege inherently has security problems. But it is well recognized that Linux's setuid facility allows programs to run by ordinary users to make use of the root account in a limited and tightly controlled way. Of course, it is also well noted that if you use setuid shell scripts in a certain shell, they can be entirely insecure. But we are talking about a well-known "program", and not a setuid "script". I really hate people who mix apples and oranges.
OK, I'll clear up a bit of confusion we seem to be having here about the setuid bit.
Normally, when you run a program, it gets run as you. This means it has all the same permissions you do, including what you can do on the filesystem.
When you run something that has the setuid bit set, it gets run as the user who owns the file (often root). This means that it has all the permissions of that user (if root, total). This is useful for GAINING privilages (su for example) or changing between users (su again, since only root can do setuid). In this case, we're talking about running something as root so it has access to a CD drive.
Most programs that are designed to be run setuid immediately drop all capabilities they don't need (Linux is pretty flexible here with POSIX CAPS). The idea is to drop all privilages we can (and carefully audit the secions of code where we do this) and then setuid everythign back over to the user that ran the program (leaving just a few additional programs left, like the ability to edit the shadow password file for "passwd"). Problems occur with this in two circumstances:
A program is setuid that wasn't designed for it:In this case, the program will be run as the user it is owned by (often root or another "privilaged" user filesystem wise, like the user bin). Since the program isn't designed to be run setuid root, it won't know to drop all these additional privilages and will just do everything as the user root. If the user can get the program to do something that it wasn't designed to do (via careful use of options or more creative tricks such as buffer overflows), this can lead to the user doing things you didn't want them doing...as root. Often, this is executing "arbitrary code" (basically doing whatever they want), which usually means "bring up a shell" as root. Once the user has this "root shell," they basically own the system as it's like they logged in as root.
A program that is designed to be run setuid root has a bug:Sometimes, programs designed to be run setuid root have a bug. XFree86, for example, would print the first line of whatever file you gave it for a config if an error occurred. Since the X server is setuid root, it can read any files (including the elusive /etc/shadow, the shadow password file containing crypted passwords). A bug was found where the user could simply specify /etc/shadow as a config file and XFree86 would flag it as an error and print the first line. Usually the first line was the entry for "root". Oops, there goes your root password (crypted, but a modern PC can brute force the entire DES keyspace in a matter of hours or at worst a few days; MD5 may take a few weeks if the user is determined). Notice that this wasn't even a buffer overflow or a condition where arbitrary code could be executed! This was just creative [ab]use of a seemingly harmless bug.
There are some things that absolutely have to be setuid root. Anything that needs to elevate privilages (su, sudo, etc), modify system config files (passwd, chfn, chsh, etc), or do stuff at a hardware level (X servers, etc) will have to be setuid root so that ordinary users can run them. There isn't anything one can do about this. It's just the way UNIX was made. There's nothing wrong with it; it just requires some careful coding (which should be standard anyway!).
Back to the CD burner/ripping subject: just give the user read/write access to the CD device (generic and block). I like to make a group or two (cdburn, cdrom) that I can add people to (usually just me on my mostly single user desktop), make the device nodes owned by this group and set mode 664 or 660 (depending on my mood). This allows any user to access the device without needing setuid bits all over the place. The only thing the setuid bit was getting you was the filesystem permissions override CAP.
X-CDRoase uses a different method. Rather than giving the user full access to the device (playing with filesytstem permissions is kinda an all or nothign thing), it uses a wrapper script (that's setuid to a certian user/group that DOES have full access to the device, often not root tho) to provide more granular control over what can be done with the device. Users then call the wrapper to do the dirty work for them.
> snip --MonMotha
pgpbi3rw38ZK6.pgp
Description: PGP signature
