Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD
Security Advisory FreeBSD-SA-07:01.jail]
Simon L. Nielsen
simon at FreeBSD.org
Sat Jan 20 12:24:35 UTC 2007
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
And in case anyone were in doubt: Computers still suck :-).
Simon L. Nielsen
More information about the freebsd-stable