[Bug 280809] jail_attach(2) fails to document reason for EPERM

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

--- Comment #3 from crest@rlwinm.de ---
There is the kern.chroot_allow_open_directories sysctl to allow chroot() with
directory file descriptors, but no such "backdoor" exists for jail_attach(),
because jails are supposed to provide secure namespace isolation. Removing this
restriction would allow trivial jail escapes through fchdir() and openat().

Allowing jailed processes to safely share directory file descriptors either
through inheritance or file descriptor passing could be very useful, but is
totally unsafe right now. Sharing directory file descriptors through
inheritance across jails is (and always has been) impossible because
jail_attach() doesn't allow processes with having one or more such file
descriptors to attach to a jail. Despite this it's possible to share file
descriptors across jails via file descriptor passing over unix domain sockets.

Passing directory file descriptors to a directory outside the receivers jail
root into a jail is an instant file system escape because the jail root is
enforced by comparing vnodes and if you `parent_fd = openat(dir_fd, "..",
O_DIRECTORY)` you won't encounter the jail root vnode. By looping until "." ==
".." the jailed process can find the hosts root filesystem. While the unix
socket could be brought into a jail via jail_attach() the more likely real
world situation would be intentionally sharing a nullfs mount across jails
(e.g. a PostgreSQL jail <-> a FastCGI jail).

One way I can think of to make it safe would be to add a O_RESOLVE_BENEATH like
write-once flag to file descriptors and allow only directory file descriptors
with this flag to be shared across jails. It would have to be inherited too
(e.g. openat(dir_fd, "<subdir>", O_DIRECTORY) on a sub-directory). If the flag
could be automatically set by jail_attach() and file descriptor passing across
jails would work without extra syscalls to set the new flag with the caveat
that ".." inaccessible on such file descriptors and those derived from them.

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