GSoC Idea: per-process filesystem namespaces for FreeBSD

[Bakul Shah]

On Mar 13, 2018, at 5:16 PM, Theron Tarigo <theron.tarigo at gmail.com> wrote:
> 
> On 03/13/18 18:23, Bakul Shah wrote:
>> Plan9 has no root (superuser) or setuid.  You can mangle
>> anything in your namespace but it affects only *your* own
>> process and its future descendents.
>> 
>> The following paper on Plan9 authentication in Linux may be
>> worth reading:
>>     https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34433.pdf
>> 
>> While I have wanted per-process namespace in BSD for a long
>> time, I agree with Konstantin this is a non-trivial project.
>> Even if the design was fully fleshed out, implementing it
>> would likely take longer than 12 weeks.
> Although it would limit the usefulness of it, ignoring any and all file suid bits for any process with a non-empty mount table should in theory prevent exploitation of setuid.  Allowing safe setuid in combination with ("trusted" ?) namespaces would be something to add support for much later if someone decides it would be useful.
> 
> By focusing on a narrowed case, that of allowing an unprivileged process to alter its view into the vfs in a way which is only preserved through execve() in specific safe circumstances, I hoped to avoid the insurmountable complexity of implementing the feature in the full generality that is available on Plan9.

IMHO this needs to be designed-in carefully as it touches upon a very
central facility of Unix. It doesn't have to be plan9 compatible but
it does need to be well integrated and be as orthogonal (widely
applicable) as possible. Plan9 design for per-process namespace is
well thought out & it should be studied. Ideally increased flexibility
provided by per-process namespaces simplifies things. chroot can be
reimplemented this way.

Any narrowing of goals should be in the context of an overall design.
Second, it is likely that many files will be affected and a
comprehensive design will force you to look at all these places.

Getting the design right will be lot more than just making mount tables
per process.

Someone mentioned Linux namespaces. The complexity of this feature
makes me think it was done the wrong way about.

> On 03/13/18 18:31, Mark Saad wrote:
>>  A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like “ FreeBSD needs a proper stacking vfs ...”   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs’s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
>> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .
>> 
> Using nullfs / unionfs in combination with chroot could be made functionally equivalent to per-process namespace, but would have the very same security problems as already discussed (as any chroot have) so configuring such environments would be available only to superuser.

Note that plan9's bind(2) mechanism is much simpler than unionfs &
the latter has never really worked well in BSD. In any case union
mounts are global.

> So it appears that the most significant obstacle to achieving at least an approximation of the behavior of user-controlled per-process namespace is managing setuid safely.

A simple initial solution may be to disallow setuid in per-user mounts.