Date: Fri, 28 Nov 2003 15:22:48 -0600 From: Charles Howse <chowse@charter.net> To: freebsd-questions@freebsd.org Subject: Re: possible solution to cdbakeoven failing to detect ATAPI burners Message-ID: <200311281522.48614.chowse@charter.net> In-Reply-To: <44ekvs4ezw.fsf@be-well.ilk.org> References: <200311271102.20318.chowse@charter.net> <200311271757.15345.chowse@charter.net> <44ekvs4ezw.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 November 2003 10:47 am, Lowell Gilbert wrote: > Charles Howse <chowse@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. 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 SA. -- Thanks, Charles http://howse.homeunix.net:8080 Random Murphy's Law: If you can get the faulty part off, the parts house will have it back-ordered.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311281522.48614.chowse>