https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285782

Mark Johnston <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
                 CC|                            |[email protected]

--- Comment #4 from Mark Johnston <[email protected]> ---
> Jails are not supposed to fail to contain their root user just because just 
> because a malicous non-root user on the host has write access to a directory 
> on the same filesystem as the jail that's also outside the jail's path.

The jail(8) man page claims exactly that:

NOTES
     Great care should be taken when managing directories visible within the
     jail.  For example, if a jailed process has its current working directory
     set to a directory that is moved out of the jail's chroot, then the
     process may gain access to the file space outside of the jail.  It is
     recommended that directories always be copied, rather than moved, out of
     a jail.

     In addition, there are several ways in which an unprivileged user outside
     the jail can cooperate with a privileged user inside the jail and thereby
     obtain elevated privileges in the host environment.  Most of these
     attacks can be mitigated by ensuring that the jail root is not accessible
     to unprivileged users in the host environment.  Regardless, as a general
     rule, untrusted users with privileged access to a jail should not be
     given access to the host environment.

See also PR 142341, which reports the same problem.

This warning should certainly be more prominent in the man page.

(In reply to Konstantin Belousov from comment #2)
I didn't test it, but I think you're right.  I wonder if we can fix this by
modifying vfs_lookup() to disallow dotdot traversal through any ancestor jail's
root directory, regardless of whether the ni_topdir/ni_rootdir checks pass.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to