Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hi Simon, Thanks very much for the patch :) On Fri, 27 Jul 2007 11:07:29 +0200, Simon L. Nielsen wrote: Your patch is very close to the correct/cleaner patch which is attached. How exactly does it fail without your patch? Does it say cannot open : No such file or directory and then no jails start when booting (that would be my guess from a quick check of the bug)? Sure does: eval: cannot open : No such file or directory and no jails start. Would it be possible for you to test the attached patch and see if it fixes the issue for you? It does indeed. I was actually pretty foolish in the way that I addressed it, now that I see what your patch does. I was so busy scratching my head at the variables before the 'while' loop that I didn't see that the problem was in the ${_fstab} being fed to it on stdin! I haven't heard of this issue before, so not many people are using 5.5 with jails. The bug was certainly introduced as a merge error in the with the patch for FreeBSD-SA-07:01.jail. Or maybe they're not patching often enough? Actually, my suspicion is that not many are using the jail_example_mount_enable variable, because without this set the responsible code is never called. As this is clearly a bug in a Security Advisory patch and RELENG_5 / RELENG_5_5 are still supported I expect that an updated advisory will be released to fix this bug shortly. Thanks for reporting the issue, and sorry about the bad patch :-(. No problem! It feels good to help :) I never implement new patches into my prod environment before testing, so this has basically been an interesting exercise for me. cheers, joel -- Joel Hatton -- Infrastructure Manager | Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hi, I'm dredging up an old issue here, but it appears to be unresolved in RELENG_5_5 at this time. After upgrading to 5.5-RELEASE-p14, I found that my jails wouldn't start anymore, and it comes down to this bit again. By way of explanation, I'll include the patch for what I changed. --- /tmp/jail Wed Feb 14 15:16:30 2007 +++ /etc/rc.d/jail Fri Jul 27 13:46:51 2007 @@ -218,7 +218,7 @@ { local _device _mountpt _rest - while read _device _mountpt _rest; do + cat ${jail_fstab} | while read _device _mountpt _rest; do case :${_device} in :#* | :) continue In short, the jail_mount_fstab function is not given the fstab file on which the local variables depend. My patch may not be the most robust but for me today it is expedient. Sorry if this has been discussed already, but I was surprised that this hadn't been fixed yet. It certainly would have caused some anxious moments if I'd upgraded a prod server with multiple jails before I realised! cheers, joel On Fri, 12 Jan 2007 04:40:59 +0100, Philipp Wuensche wrote: Mark Andrews wrote: I'm not sure I understand that quite correct, where is this problem appearing? Other things: tail is used in line 230: tail -r ${_fstab} | while read _device _mountpt _rest; do If the per-jail fstab is larger than 10 lines, which is the default of tail to show, the remaining mountpoints will not be unmounted? The default for the -r option is to display all of the input. Ah, didn't know that. Thanks for correcting me there. greetings, philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
On 2007.07.27 17:12:34 +1000, Joel Hatton wrote: I'm dredging up an old issue here, but it appears to be unresolved in RELENG_5_5 at this time. After upgrading to 5.5-RELEASE-p14, I found that my jails wouldn't start anymore, and it comes down to this bit again. By way of explanation, I'll include the patch for what I changed. --- /tmp/jail Wed Feb 14 15:16:30 2007 +++ /etc/rc.d/jail Fri Jul 27 13:46:51 2007 @@ -218,7 +218,7 @@ { local _device _mountpt _rest - while read _device _mountpt _rest; do + cat ${jail_fstab} | while read _device _mountpt _rest; do case :${_device} in :#* | :) continue In short, the jail_mount_fstab function is not given the fstab file on which the local variables depend. My patch may not be the most robust but for me today it is expedient. Hey, Yes, looking at the code now it is clearly wrong. Guess I/we (secteam) stared too much at the code so we missed this issue :-/. Your patch is very close to the correct/cleaner patch which is attached. How exactly does it fail without your patch? Does it say cannot open : No such file or directory and then no jails start when booting (that would be my guess from a quick check of the bug)? Would it be possible for you to test the attached patch and see if it fixes the issue for you? Sorry if this has been discussed already, but I was surprised that this hadn't been fixed yet. It certainly would have caused some anxious moments if I'd upgraded a prod server with multiple jails before I realised! I haven't heard of this issue before, so not many people are using 5.5 with jails. The bug was certainly introduced as a merge error in the with the patch for FreeBSD-SA-07:01.jail. As this is clearly a bug in a Security Advisory patch and RELENG_5 / RELENG_5_5 are still supported I expect that an updated advisory will be released to fix this bug shortly. Thanks for reporting the issue, and sorry about the bad patch :-(. -- Simon L. Nielsen Hat: FreeBSD Security Team and pointyhat Index: jail === RCS file: /home/ncvs/src/etc/rc.d/jail,v retrieving revision 1.15.2.5.2.1 diff -u -d -r1.15.2.5.2.1 jail --- jail11 Jan 2007 18:19:33 - 1.15.2.5.2.1 +++ jail27 Jul 2007 08:49:37 - @@ -228,7 +228,7 @@ warn ${_mountpt} has symlink as parent - not mounting from ${jail_fstab} return fi - done ${_fstab} + done ${jail_fstab} mount -a -F ${jail_fstab} } pgpfkwZGUCy2V.pgp Description: PGP signature
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On Sat, Jan 20, 2007 at 03:24:23PM +0100, Alexander Leidinger wrote: Quoting Pawel Jakub Dawidek [EMAIL PROTECTED] (Sat, 20 Jan 2007 14:03:08 +0100): I fully agree that console.log should be outside a jail. At least noone proposed safe solution so far, which also means it's not an easy fix. What's unsafe about my proposal? I did had a look at the code now, and it should work (with minor mods). Original: ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ eval jail ${_flags} -i ${_rootdir} ${_hostname} \ ${_ip} ${_exec_start} ${_tmp_jail} 21 if [ $? -eq 0 ] ; then _jail_id=$(head -1 ${_tmp_jail}) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname tail +2 ${_tmp_jail} ${_consolelog} echo ${_jail_id} /var/run/jail_${_jail}.id ---snip--- Pseudocode proposal, not tested (changes prefixed with 'x'): ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ x # assuming safe _consolelog (inside chroot) according to the x # previous mails here in the thread x eval (echo ; \ x jail ${_flags} -I /var/run/jail_${_jail}.id \ x ${_rootdir} ${_hostname} {_ip} ${_exec_start}) \ x${_consolelog} 21 if [ $? -eq 0 ] ; then x _jail_id=$(cat /var/run/jail_${_jail}.id) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname x x ---snip--- Repeating my points: - sanitize the consolelog path like discussed in this thread - the jail is not running, so nobody can create a link (jail root within FS space of another jail still prohibited) - subshell to group echo and jail - 'echo ' to make sure the file exists when the jail starts - (new) additional flag to jail to write a jid file - redirect to the consolelog, it is still open from the echo when the jail starts so there's no race I did test (echo 1; sleep 60 ; echo 2) /tmp/test in /bin/sh, and it is line buffered, so the above works. Where's the security problem in the above? It looks like it may work, but I still find it a bit risky. If sh(1) can reopen the file under some conditions or someone in the future will modify sh(1) in that way (because he won't be aware that such a change may have impact on system security) we will have a security hole. Chances are small, but I'm not going to be the one who will accept that change:) -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpxJyediGS02.pgp Description: PGP signature
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
Quoting Pawel Jakub Dawidek [EMAIL PROTECTED] (from Tue, 23 Jan 2007 12:34:44 +0100): On Sat, Jan 20, 2007 at 03:24:23PM +0100, Alexander Leidinger wrote: Quoting Pawel Jakub Dawidek [EMAIL PROTECTED] (Sat, 20 Jan 2007 14:03:08 +0100): I fully agree that console.log should be outside a jail. At least noone proposed safe solution so far, which also means it's not an easy fix. What's unsafe about my proposal? I did had a look at the code now, and it should work (with minor mods). Original: ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ eval jail ${_flags} -i ${_rootdir} ${_hostname} \ ${_ip} ${_exec_start} ${_tmp_jail} 21 if [ $? -eq 0 ] ; then _jail_id=$(head -1 ${_tmp_jail}) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname tail +2 ${_tmp_jail} ${_consolelog} echo ${_jail_id} /var/run/jail_${_jail}.id ---snip--- Pseudocode proposal, not tested (changes prefixed with 'x'): ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ x # assuming safe _consolelog (inside chroot) according to the x # previous mails here in the thread x eval (echo ; \ x jail ${_flags} -I /var/run/jail_${_jail}.id \ x ${_rootdir} ${_hostname} {_ip} ${_exec_start}) \ x${_consolelog} 21 if [ $? -eq 0 ] ; then x _jail_id=$(cat /var/run/jail_${_jail}.id) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname x x ---snip--- Repeating my points: - sanitize the consolelog path like discussed in this thread - the jail is not running, so nobody can create a link (jail root within FS space of another jail still prohibited) - subshell to group echo and jail - 'echo ' to make sure the file exists when the jail starts - (new) additional flag to jail to write a jid file - redirect to the consolelog, it is still open from the echo when the jail starts so there's no race I did test (echo 1; sleep 60 ; echo 2) /tmp/test in /bin/sh, and it is line buffered, so the above works. Where's the security problem in the above? It looks like it may work, but I still find it a bit risky. If sh(1) can reopen the file under some conditions or someone in the future will modify sh(1) in that way (because he won't be aware that such a change may have impact on system security) we will have a security hole. Chances are small, but I'm not going to be the one who will accept that change:) The spawned subshell is like a command. It doesn't make sense to reopen the file for a command. It's like saying we open and close the file for each line. I didn't calculated the probability of this to happen, but I would be very surprised if it is significant. Just think about the performance of such behavior (or a more complex logic which open()/close()es in a more complex way). And if you think about such unlikely stuff to happen, you should also think about some other stuff we are not prepared to survive. But feel free to propose a better solution for the problem. Bye, Alexander. -- In Newark the laundromats are open 24 hours a day! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On Tue, Jan 23, 2007 at 01:25:08PM +0100, Alexander Leidinger wrote: Quoting Pawel Jakub Dawidek [EMAIL PROTECTED] (from Tue, 23 Jan 2007 12:34:44 +0100): It looks like it may work, but I still find it a bit risky. If sh(1) can reopen the file under some conditions or someone in the future will modify sh(1) in that way (because he won't be aware that such a change may have impact on system security) we will have a security hole. Chances are small, but I'm not going to be the one who will accept that change:) The spawned subshell is like a command. It doesn't make sense to reopen the file for a command. It's like saying we open and close the file for each line. I didn't calculated the probability of this to happen, but I would be very surprised if it is significant. Just think about the performance of such behavior (or a more complex logic [...] And if you think about such unlikely stuff to happen, you should also think about some other stuff we are not prepared to survive. [...] Come on, this argument always stands. I only wanted to point out that we should be extra careful with building security on top of tools that are not intended for this purpose. [...] But feel free to propose a better solution for the problem. The solution was proposed already - keep console.log outside of jail. Don't read my comment as a no vote for your solution. If secteam@ decide there is nothing to be worry about - fine by me. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpq64ac0jGwG.pgp Description: PGP signature
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hi Colin, On Thu, Jan 11, 2007 at 04:51:02PM -0800, Colin Percival wrote: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). While this is not ideal, this security issue was extraordinarily messy due to the power and flexibility of the jails and the jail rc.d script. I can't recall any other time when the security team has spent this long trying to find a working patch for a security issue. I'd like to publicly thank Simon Nielsen for the many many hours he spent working on this issue, as well as the release engineering team for being very patient with us and delaying the upcoming release to give us time to fix this. Thank you very much to Simon Nielsen for the work being accomplished. According to the patch itself, it is clear he should have spent much time to resolve this issue. However both Pawel and Dirk seem to have proposed less limitating solutions. I understand we are talking about security and we may not have much time experimenting every solutions on RELENG_6. Nonetheless CURRENT the one place to experiment such solutions with a larger audience and I would be very pleased to see a less restrictive workaround for this problem. Indeed I'm using the same setup as Pawel (/jail - /usr/jail). Thank you for your work as a security officer. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On 2007.01.13 12:29:37 +0100, Pawel Jakub Dawidek wrote: On Thu, Jan 11, 2007 at 04:51:02PM -0800, Colin Percival wrote: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). So, I have been putting off replying to this thread, but I guess it seems like I should reply... :-) I don't like the way it was fixed. I do know it wasn't easy to fix. I don't like it either, but it was the best of bad solutions. My hope while developing the patch, and cursing computers in general :-), was that after the Security Advisory went out somebody would implement a fix which sucks less possibly by modifying some of the support tools. Your suggestion with modifying realpath to use chroot(2) certainly sounds like it could work, but I haven't thought about it in great detail if there are problems. The Security Team does not hold a lock on trying to improve the fix in src/etc/rc.d/jail, but anyone that does change the fix from the Security Advisory should be really really really really (did I mention really?) sure the fix is safe and have at least a few people with security clue review patches. It is very easy to get this wrong (my first patch did). Also, whatever fix is made should be in -CURRENT for a while (3 weeks min. IMO) before being MFC'ed, both because it gives more time for people to think about the fix and because -CURRENT isn't supported wrt. security issues, so if the fix is wrong we don't have to issue an advisory. BTW. with regard to the console.log file I really don't think it should be put back inside the jail unless it's possible to make the generation of the file entirely inside the jail since it's just not worth the risk/complexity. I think it should be possible to do this with jail(8) in -CURRENT (see -J flag), but: Note that it will probably be at least a couple of weeks before I feel like going anywhere near the jail rc.d script again (except for the warning comment I plan to add...), so don't wait for me with regard to improving this. And in case anyone were in doubt: Computers still suck :-). -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On Sat, Jan 20, 2007 at 01:24:33PM +0100, Simon L. Nielsen wrote: [...] BTW. with regard to the console.log file I really don't think it should be put back inside the jail unless it's possible to make the generation of the file entirely inside the jail since it's just not worth the risk/complexity. I think it should be possible to do this with jail(8) in -CURRENT (see -J flag), but: When -J operates on a file inside a jail, it create the same security hole as the one from security advisory, because it opens a file before calling jail(2). I fully agree that console.log should be outside a jail. At least noone proposed safe solution so far, which also means it's not an easy fix. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp1bmSk2cQlL.pgp Description: PGP signature
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On 2007.01.20 14:03:08 +0100, Pawel Jakub Dawidek wrote: On Sat, Jan 20, 2007 at 01:24:33PM +0100, Simon L. Nielsen wrote: [...] BTW. with regard to the console.log file I really don't think it should be put back inside the jail unless it's possible to make the generation of the file entirely inside the jail since it's just not worth the risk/complexity. I think it should be possible to do this with jail(8) in -CURRENT (see -J flag), but: When -J operates on a file inside a jail, it create the same security hole as the one from security advisory, because it opens a file before calling jail(2). My thought with using -J was not place the info about jid in a file outside the jail root, basically (pseudo code): _tmpfile=`mktemp...` jail -J $_tmpfile sh /etc/rc /var/log/console.log _jid=`cat $_tmpfile | something` At least that was what I thought might be possible with the -J switch when I noticed it existed. In any case, actually coding this, verifying that it works and is safe is left up to anyone who cares about having console.log inside the jail. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pawel Jakub Dawidek wrote: When -J operates on a file inside a jail, it create the same security hole as the one from security advisory, because it opens a file before calling jail(2). I fully agree that console.log should be outside a jail. At least noone proposed safe solution so far, which also means it's not an easy fix. I still suggest using pwd -P to get the real path and using the shell's CWD as a lock. That works safely with mount(8) at least. Comments? erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFsiGzImmQdUyYEgkRAlKcAJ4izD1J4x6jDDfvrtr5J+bcmSxK/ACfRpwn x5yVH4uJIN7CWEgYtATKDE0= =sQq3 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
Quoting Pawel Jakub Dawidek [EMAIL PROTECTED] (Sat, 20 Jan 2007 14:03:08 +0100): I fully agree that console.log should be outside a jail. At least noone proposed safe solution so far, which also means it's not an easy fix. What's unsafe about my proposal? I did had a look at the code now, and it should work (with minor mods). Original: ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ eval jail ${_flags} -i ${_rootdir} ${_hostname} \ ${_ip} ${_exec_start} ${_tmp_jail} 21 if [ $? -eq 0 ] ; then _jail_id=$(head -1 ${_tmp_jail}) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname tail +2 ${_tmp_jail} ${_consolelog} echo ${_jail_id} /var/run/jail_${_jail}.id ---snip--- Pseudocode proposal, not tested (changes prefixed with 'x'): ---snip--- _tmp_jail=${_tmp_dir}/jail.$$ x # assuming safe _consolelog (inside chroot) according to the x # previous mails here in the thread x eval (echo ; \ x jail ${_flags} -I /var/run/jail_${_jail}.id \ x ${_rootdir} ${_hostname} {_ip} ${_exec_start}) \ x${_consolelog} 21 if [ $? -eq 0 ] ; then x _jail_id=$(cat /var/run/jail_${_jail}.id) i=1 while [ true ]; do eval out=\\${_exec_afterstart${i}:-''}\ if [ -z $out ]; then break; fi jexec ${_jail_id} ${out} i=$((i + 1)) done echo -n $_hostname x x ---snip--- Repeating my points: - sanitize the consolelog path like discussed in this thread - the jail is not running, so nobody can create a link (jail root within FS space of another jail still prohibited) - subshell to group echo and jail - 'echo ' to make sure the file exists when the jail starts - (new) additional flag to jail to write a jid file - redirect to the consolelog, it is still open from the echo when the jail starts so there's no race I did test (echo 1; sleep 60 ; echo 2) /tmp/test in /bin/sh, and it is line buffered, so the above works. Where's the security problem in the above? Bye, Alexander. -- I wore my extra loose pants for nothing. Nothing! -- Homer Simpson New Kid on the Block http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
* Colin Percival [EMAIL PROTECTED] [12.01.2007 06:53]: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). While this is not ideal, this security issue was extraordinarily messy due to the power and flexibility of the jails and the jail rc.d script. I can't recall any other time when the security team has spent this long trying to find a working patch for a security issue. I'd like to publicly thank Simon Nielsen for the many many hours he spent working on this issue, as well as the release engineering team for being very patient with us and delaying the upcoming release to give us time to fix this. The other approach to write log file safely is to do it from the process running inside a jail. As an example, there is a ports/sysutils/jailer that does that (with small modification). Here are small patches that fix it to work on FBSD 4 and allows it to write to log file instead of console: http://kaya.nov.net/frol/patches/jailer-1.1.2-fbsd5-console.diff http://kaya.nov.net/frol/patches/jailer-1.1.2-injail-sysctl.diff wbrw, dmitry. -- Dmitry Frolov [EMAIL PROTECTED] RISS-Telecom Network, Novosibirsk, Russia [EMAIL PROTECTED], +7 383 2278800, DVF-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
On Thu, Jan 11, 2007 at 04:51:02PM -0800, Colin Percival wrote: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). I don't like the way it was fixed. I do know it wasn't easy to fix. I don't like it because it breaks almost all my current jails, because I often use /jails/ paths in fstabs, which is actually a symlink to /usr/jails/. What I'd like to suggest, which seems much better way to fix the problem is: 1. Apply the patch: http://people.freebsd.org/~pjd/patches/realpath.patch 2. Find full path to jail's root with `realpath $_rootdir`. 3. Take first entry from /etc/fstab.name, for example we have a mount-point /usr/jails/foo/usr/lib in there. Run `realpath /usr' and compare with $_rootfulldir, if doesn't match, run `realpath /usr/jails` and compare, if doesn't match take next path component until we find a match. When a match is found, what's left out is a mount-point inside a jail, eg. '/usr/lib'. Now, run real=`realpath -c $_rootdir /usr/lib`, which will give us full path inside a jail. Then, we need to mount file system on $_rootdir/$real. 4. Repeat 3 for each fstab entry. With this approch one can use symlinks in any mount-point component. The whole complexity in point 3, is because people can have jail's root configured as '/usr/jails/foo', but use '/jails/foo' prefix for mount-points. I'll keep /var/log/console.log outside a jail, because using 'realpath -c' will be dangerous once the jail is running. There could be a race where `realpath -c` returns one path, an attacker inside a jail changes one of resolved path's component and rc.d/jail from outside a jail tries to use it. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpSbbFVrYgiw.pgp Description: PGP signature
HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail), make an assumption about how systems are configured (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). While this is not ideal, this security issue was extraordinarily messy due to the power and flexibility of the jails and the jail rc.d script. I can't recall any other time when the security team has spent this long trying to find a working patch for a security issue. I'd like to publicly thank Simon Nielsen for the many many hours he spent working on this issue, as well as the release engineering team for being very patient with us and delaying the upcoming release to give us time to fix this. Sincerely, Colin Percival FreeBSD Security Officer FreeBSD Security Advisories wrote: = FreeBSD-SA-07:01.jail Security Advisory The FreeBSD Project Topic: Jail rc.d script privilege escalation [snip] NOTE WELL: The solution described changes the default location of the console.log for jails from /var/log/console.log inside each jail to /var/log/jail_${jail_name}_console.log on host system. If this is a problem, it may be possible to create a hard link from the new position of the console log file to a location inside the jail. A new rc.conf(5) variable, jail_${jail_name}_consolelog, can be used to change the location of console.log files on a per-jail basis. In addition, the solution described below does not fully secure jail configurations where two jails have overlapping directory trees and a file system is mounted inside the overlap. Overlapping directory trees can occur when jails share the same root directory; when a jail has a root directory which is a subdirectory of another jail's root directory; or when a part of the file system space of one jail is mounted inside the file system space of another jail, e.g., using nullfs or unionfs. To handle overlapping jails safely the administrator must set the sysctl(8) variable security.jail.chflags_allowed to 0 (the default) and manually set the sunlnk file/directory flag on all mount points and all parent directories of mount points. If this is done while jails are running, the adminstrator must check that an attacker has not replaced any directories with symlinks after setting the sunlnk flag. [snip] The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-07:01.jail.asc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Colin Percival wrote: Hello Everyone, I usually let security advisories speak for themselves, but I want to call special attention to this one: If you use jails, READ THE ADVISORY, in particular the NOTE WELL part below; and if you have problems after applying the security patch, LET US KNOW -- we do everything we can to make sure that security updates will never cause problems, but in this case we could not fix the all of the security issues without either making assumptions about how systems are configured or reducing functionality. In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail) Thats a bummer, when Dirk showed me this problem the first time my ideas for fixing this problem without losing the functionality where changing flags on the file so it can't be removed or/and checking if it is really a file or a symlink instead. Of course you have to check if /var/log has symlinked parent directories before. First is quite problematic and setting flags on file is something scripts which create a jail in the first place probably have to bother with so option two would be my approach. Did I miss a possible problem with that idea? (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and If I understand the patch correct it checks recursive all parent directories of a mountpoint in is_symlinked_mountpoint(), wouldn't it be better to just check for a symlinked parent directory up to and not including ${_rootdir}? I think that wouldn't weaken security and people would be allowed to use symlinks for their jail root-directories and above. I already know some setups which will break with the current patch. leave a potential security problem unfixed (if you mount any filesystems via per-jail fstab files on mount points which are visible within multiple jails, there are problems -- don't do this). I'm not sure I understand that quite correct, where is this problem appearing? Other things: tail is used in line 230: tail -r ${_fstab} | while read _device _mountpt _rest; do If the per-jail fstab is larger than 10 lines, which is the default of tail to show, the remaining mountpoints will not be unmounted? Anyway thanks to the freebsd team. greetings, philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Mark Andrews wrote: I'm not sure I understand that quite correct, where is this problem appearing? Other things: tail is used in line 230: tail -r ${_fstab} | while read _device _mountpt _rest; do If the per-jail fstab is larger than 10 lines, which is the default of tail to show, the remaining mountpoints will not be unmounted? The default for the -r option is to display all of the input. Ah, didn't know that. Thanks for correcting me there. greetings, philipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
I'm not sure I understand that quite correct, where is this problem appearing? Other things: tail is used in line 230: tail -r ${_fstab} | while read _device _mountpt _rest; do If the per-jail fstab is larger than 10 lines, which is the default of tail to show, the remaining mountpoints will not be unmounted? The default for the -r option is to display all of the input. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Philipp Wuensche wrote: Colin Percival wrote: In the end we opted to reduce functionality (the jail startup process is no longer logged to /var/log/console.log inside the jail) Thats a bummer, when Dirk showed me this problem the first time my ideas for fixing this problem without losing the functionality where changing flags on the file so it can't be removed or/and checking if it is really a file or a symlink instead. Of course you have to check if /var/log has symlinked parent directories before. First is quite problematic and setting flags on file is something scripts which create a jail in the first place probably have to bother with so option two would be my approach. Did I miss a possible problem with that idea? Assuming that option two means use file flags to make sure that the host can write to the jailed /var/log/console.log securely, setting the sunlnk flag on the jail's /var and /var/log would probably break many jails -- for one thing, log rotation would become impossible. Then there's the problem of systems with chflags_allowed=1... (filesystems which are mounted via per-jail fstab files should not be mounted on symlinks -- if you do this, adjust your fstab files to give the real, non-symlinked, path to the mount point), and If I understand the patch correct it checks recursive all parent directories of a mountpoint in is_symlinked_mountpoint(), wouldn't it be better to just check for a symlinked parent directory up to and not including ${_rootdir}? This option never occurred to me; I _think_ it would work, but it would require canonicalizing the jail root path... even if I had thought of this, I might have decided to avoid this on the basis that complexity == bugs == bad for security patches. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]