On Friday 28 November 2003 10:47 am, Lowell Gilbert wrote:
> Charles Howse <[EMAIL PROTECTED]> 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.

This is excellent foor for thought!  I'm going to audit my security policy for 
the lan here at home, and will make a note to remind myself to be sure to 
explain that not everything I do here at home is suitable for the corporate 


Random Murphy's Law:
If you can get the faulty part off, the parts house
will have it back-ordered.

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to