GSoC Idea: per-process filesystem namespaces for FreeBSD

[Theron Tarigo]

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.

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.

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.

One thought I had is to do all of this purely in user-space by creating 
an extension to libc which allows appropriately linked programs to find 
files according to some set of prefixes defining the namespace, defined 
through an environment variable, but have all system interactions 
function in the normal ways.  Would this be sufficiently general to be 
of any use?  If this approach does pose any security threats, it 
indicates a hole is already present in the system! (MacOS once had a 
problem with allowing privileged programs to be launched under a 
modified library path...)

On 03/13/18 20:00, Mark Saad wrote:
> However I still think the unionfs / nullfs work I mentioned before 
> would be a good project related to the plan9 idea in some ways .
Is there a way I could go about fixing up unionfs while also making 
significant progress towards eventual support for true per-process 
namespace?

Theron