[luau] Duplicating Music CD

W. Wayne Liauh LiauhW001 at Hawaii.rr.com
Mon Dec 9 18:30:01 PST 2002


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






More information about the LUAU mailing list