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. - 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" _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
