https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285782
--- Comment #3 from [email protected] --- (In reply to Konstantin Belousov from comment #2) All the way back to the original whitepaper jails are about containing the "omnipotent root". Imagine two parent directories with 1777 (e.g. the respective /tmp) and an attacker with an unprivileged account on the host and root inside a jail. In this case the attacker can use the unprivileged account to move the working directory of a jailed root shell outside of the jail. Allowing the supposedly securely jailed shell to "enjoy" full write access to full filesystem. You shouldn't be able to get past any of your anchestor jail root directories along the path because vfs_lookup() loops over all of them in search for a matching root directory vnode. Calling it "self-inflicted damage" is flat out wrong. 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. At least I'm not aware of any (official) documentation that **loudly** warns potential users that jails must always be configured with $path resolving to the root directory of a mounted filesystem. Instead I consider it a viable **local** privilege escalation, because it allows an attacker to combine an **unprivileged** account on the host and root **inside** a jail to gain root over the **whole** system. The following jail.conf snippet should work as a workaround without breaking if the nullfs is already mounted: exec.prepare += " mount -F /dev/stdin <<- 'EOF' $path $path nullfs rw 0 0 EOF "; -- You are receiving this mail because: You are the assignee for the bug.
