[luau] Duplicating Music CD

[MonMotha]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 252 bytes
Desc: not available
URL: <http://lists.freesoftwarehawaii.org/pipermail/luau-freesoftwarehawaii.org/attachments/20021209/7ee38098/attachment-0001.pgp>