https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285782
--- Comment #12 from Olivier Certner <[email protected]> --- (In reply to crest from comment #11) > The problem isn't just allowing such rename()s, but that afterward moved > directory's ".." entry can be used esacape the jail. Of course. But these behaviors are not separable. > I consider the "don't move directories" answer bullshit, because **any** > unjailed user can help a jailed **root** user escape its root path while > keeping root privileges on filesystem operations. So you're effectively > telling users all host users have to be treated as equivalent to passwordless > sudo to root unless the issue is mitigated (...) Please... That's not what we said, and that's not true. Users on the host cannot do any such thing if they don't have access to the jail's file hierarchy. And there is absolutely no reason that they should. That said, there are other potential escape scenarios when a host user collaborates with some jail's root. > even if I understand that always scanning if the jail root vnode can be found > along the ".." chain of a jailed process when traversing through ".." (and > fchdir() + any *at() syscalls) is ugly and would introduce painful overhead. It's probably worse than you think (path checks, vnode concurrency, revalidation when the hierarchy changed, etc.). > No user who doesn't happen to also be a kernel developer who has worked on > the jail subsystem (...) Such a dangerous glaring limitations deserves its on > SECURITY (...) Well, there are NOTES. I don't dispute it's probably insufficient. We typically have SECURITY CONSIDERATIONS sections in manual pages when relevant. There's also the security(7) manual page, which incidentally doesn't have a section on jails, which we could grow. The only thing I disagree with is that you need to be a kernel developer to understand the written NOTES: They only require practical knowledge of UNIX file system semantics, which is not so simple at times. If you find the text too terse, please feel free to propose improvements (in the form of more explanations, an example, or whatever you deem useful to help understand). > Maybe having a nullfs-light pseudo-fs (jailfs?) that only rewrites its root > directory would be less fragile than making each filesystem jail aware enough > to handle this case? (...) I don't think we'll ever want to do that in each and every filesystem. This would have to be common VFS code (with proper measures not to apply to any lookup). In the current VFS design, it's impossible to have a stackable filesystem doing that. And things are not going to be simple, they will require some changes to the common machinery (e.g., we have no idea of which jail a vnode is the root of during a lookup, in fact we don't even know that a vnode is some jail's root), which obviously would have to be carefully designed, which takes time. I seem to have much more pressing issues for 15.0 (and even 14.3), so don't expect me to spend that time before them. Please stick to the following advices: 1. Disallow host users to see some jail's files. OR 2. Make sure that a jail's root is also a filesystem root. Any of them is enough to prevent what you reported. Ideally, make sure that both apply, if you fear one of them could be inadvertently violated in your setups. -- You are receiving this mail because: You are the assignee for the bug.
