Re: possible solution to cdbakeoven failing to detect ATAPI burners
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]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
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 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
possible solution to cdbakeoven failing to detect ATAPI burners
Hi, There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. Then start cdbakeoven, enter the Settings dialog, click the CDROM Devices icon, click the scanbus tab, click the rescan button. Doing that detected my atapi burner as a scsi device! Next, I clicked the Customize Defaults icon, and ticked 'do scanbus automatically'. Then I closed cdbakeoven, restarted it, and my atapi burner was detected! I hope this works for you! -- Thanks, Charles http://howse.homeunix.net:8080 Random Murphy's Law: An original idea can never emerge from committee in its original form. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
Charles Howse [EMAIL PROTECTED] writes: There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. In other words, it's still not being run as an ordinary user... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
On Thursday 27 November 2003 11:16 am, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. In other words, it's still not being run as an ordinary user... cdbakeoven *is* being run as an ordinary user, which was the original issue, but to detect an atapi burner, it has to do 'cdrecord -scanbus', which will fail if not run as root. Make sense? -- Thanks, Charles http://howse.homeunix.net:8080 Random Murphy's Law: If there was any justice in this world, people would occasionally be permitted to fly over pigeons. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
Charles Howse wrote: On Thursday 27 November 2003 11:16 am, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. In other words, it's still not being run as an ordinary user... cdbakeoven *is* being run as an ordinary user, which was the original issue, but to detect an atapi burner, it has to do 'cdrecord -scanbus', which will fail if not run as root. Make sense? You can simply give a normal user rw-access to /dev/cd*, /dev/xpt* and /dev/pass* and it works too. No need to set suid cdrecord. IMHO a much better solution. Holger ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
Charles Howse [EMAIL PROTECTED] writes: On Thursday 27 November 2003 11:16 am, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. In other words, it's still not being run as an ordinary user... cdbakeoven *is* being run as an ordinary user, which was the original issue, but to detect an atapi burner, it has to do 'cdrecord -scanbus', which will fail if not run as root. Make sense? I understood perfectly, but I don't think you've thought through all the implications. The process executing cdrecord is *not* being run as a normal user. The process is actually running as uid zero, which is to say that it's running as *root*. This is considerably less secure than running as the user's own uid. Thus, for systems where you're worried about the security with regard to local users, you are *vastly* worse off by making the executable suid-root. There's a reason that the standard security scripts report to you *every* *night* on any new suid executables on the system. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
On Thursday 27 November 2003 05:12 pm, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: On Thursday 27 November 2003 11:16 am, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: There has been signifigant discussion here in the past about cdbakeoven not detecting ATAPI burners when run as an ordinary user. I had this issue, and may have a solution. Be sure your kernel is compiled with device atapicam. As root do: # chmod u+s /usr/local/bin/cdrecord Which will allow cdrecord to run as suid root. In other words, it's still not being run as an ordinary user... cdbakeoven *is* being run as an ordinary user, which was the original issue, but to detect an atapi burner, it has to do 'cdrecord -scanbus', which will fail if not run as root. Make sense? I understood perfectly, but I don't think you've thought through all the implications. The process executing cdrecord is *not* being run as a normal user. The process is actually running as uid zero, which is to say that it's running as *root*. This is considerably less secure than running as the user's own uid. Thus, for systems where you're worried about the security with regard to local users, you are *vastly* worse off by making the executable suid-root. I agree with you 100%. Though I didn't say it explicitly, my comments were directed not to administrators where there is concern for local user security, but to plain ordinary desktop users who just want to burn some CD's. For example, I have a home lan, I am root on all 3 machines, no one else in the house uses these machines. I am behind a hardware firewall with no ports forwarded to this machine (the one with the burner). I feel completely secure running cdrecord suid root. -- Thanks, Charles http://howse.homeunix.net:8080 Random Murphy's Law: Don't make your doctor your heir. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
Charles Howse [EMAIL PROTECTED] writes: I agree with you 100%. Though I didn't say it explicitly, my comments were directed not to administrators where there is concern for local user security, but to plain ordinary desktop users who just want to burn some CD's. In my opinion, it is quite important to be explicit about security tradeoffs when posting to a public mailing list that is frequently searched by novice sysadmins. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible solution to cdbakeoven failing to detect ATAPI burners
On Thursday 27 November 2003 05:47 pm, Lowell Gilbert wrote: Charles Howse [EMAIL PROTECTED] writes: I agree with you 100%. Though I didn't say it explicitly, my comments were directed not to administrators where there is concern for local user security, but to plain ordinary desktop users who just want to burn some CD's. In my opinion, it is quite important to be explicit about security tradeoffs when posting to a public mailing list that is frequently searched by novice sysadmins. I will take that as good advice. :-) 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. If I have more information on the implications of suid-root, I may be more careful in the future. 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. -- Thanks, Charles http://howse.homeunix.net:8080 Random Murphy's Law: If it's good they will stop making it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
