Date: Sat, 20 Jan 2007 13:24:33 +0100 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail] Message-ID: <20070120122432.GA971@zaphod.nitro.dk> In-Reply-To: <20070113112937.GI90718@garage.freebsd.pl> References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <20070113112937.GI90718@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070120122432.GA971>