Very good point(s). Again, I don't think we can discuss the setuid
issue without realizing that we are talking about (1) a
consumer-oriented desktop, for which there is necessarily a recognizedly
lesser level of security that needs to be implemented, and (2) a set of
CDROM-associated programs that are designed to have their setuid turned
on (i.e., w/o the options that may cause buffer overflow concerns or
other known security issues). When an executable file has its SUID bit
set, the file's owner owns the resulting process, no matter who launched
it. Of course we don't want the SUID bit to be set for every executable
program, but sometimes, such as su, sudo as you mentioned, or a printing
program such as lpr, this is a necessary evil.
OTOH, you are also exactly right on the wrapper script that's setuid to
a certian group that has full access to the CDROM and CD Player. In
order to run cdparanoia or cdda2wav, you also have me make yourself
member of a group called "xcdwrite".
MonMotha wrote:
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
