possible solution to cdbakeoven failing to detect ATAPI burners

[Lowell Gilbert]

Charles Howse <chowse at charter.net> writes:

> No disrespect, but seriously, can you give me a scenario where something bad 
> could happen on *my* computer because I'm running cdrecord suid-root?
> 
> I would also be very interested to hear a scenario where something bad could 
> happen on an insecure system if they are running cdrecord suid-root.

This is a very important question indeed.  The answer is kind of
complicated, because of course, if any such detailed scenario existed,
that would constitute a bug in cdrecord, and the immediate solution
would be to fix it.  The problem comes from the reverse problem:
assuring yourself that no such bug exists.

Because a negative proof is impossible, you want to reduce your
possible exposure to these problems where possible.  This is why the
Cheswick, Bellovin, and Rubin book (http://www.wilyhacker.com/)
includes the principle of least privilege ("Don't give a person or
program any more privileges than those he needs to do his job.") as
one of the "security truisms" right up front.

I should also note that the risk scenarios for your system involve not
just a problem with cdrecord, but also a way for a hostile user (or
program) to execute it, which would involve your system being at least
slightly penetrated to begin with.  On a less secure system, the
hostile might actually have an account, and just being able to
interfere with some else's use of the CD drive would be a security
problem in its own right.

> If I have more information on the implications of suid-root, I may be more 
> careful in the future.

In most cases, suid-root is used to make something more convenient
(ignoring the small number of actually essential cases in the base
system).  Security is always a tradeoff with convenience, and only the
clinically paranoid choose security in every case.

My logic for choosing security in this case is that cdrecord can be
exactly as convenient to use without root privileges; it's not a
blanket opposition to suid-root binaries.  

> Actually, I got my idea from man cdrecord, where it says:
> 
>   If you don't want to  allow  users  to  become  root  on  your  system,
>        cdrecord  may safely be installed suid root. This allows all users or a
>        group of users with no root privileges to use  cdrecord.   Cdrecord  in
>        this  case  checks,  if  the real user would have been able to read the
>        specified files.  To give all user access to use cdrecord, enter:
> 
>             chown root /usr/local/bin/cdrecord
>             chmod 4711 /usr/local/bin/cdrecord
> 
>        To give a restricted group of users access to cdrecord enter:
> 
>             chown root /usr/local/bin/cdrecord
>             chgrp cdburners /usr/local/bin/cdrecord
>             chmod 4710 /usr/local/bin/cdrecord
> 
>        and add a group cdburners on your system.

Yes; in fact, cdrecord has been audited, albeit not nearly as
carefully as critical system programs, so there is a bit more reason
to trust it than the run-of-the-mill program.

Also note the difference between the two approaches described there.
In the second, only limited users have permissions to run the program;
this means that a vulnerability in your web server wouldn't give
access to cdrecord to anybody on the Internet (assuming, of course,
that your web server doesn't run as root).

Aside from the book I mentioned before, I recommend the man page for
security(7) as a pretty good introduction to the concepts of handling
privilege.  Both references are quite good at avoiding overweaning
paranoia, which is a very common problem with security advice.

 - Lowell Gilbert
-- 
References:
 Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition
     William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubin
     ISBN:  0-201-63466-X
 "man 7 security"