Date: Wed, 14 Mar 2018 09:01:47 -0400 From: Mark Saad <nonesuch@longcount.org> To: Theron Tarigo <theron.tarigo@gmail.com> Cc: Bakul Shah <bakul@bitblocks.com>, Warner Losh <imp@bsdimp.com>, Kristoffer Eriksson <ske@pkmab.se>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: GSoC Idea: per-process filesystem namespaces for FreeBSD Message-ID: <CAMXt9NZyhJFEq0BAwXWXaLb1h0vQHaio-F4whZ6Y789bGsYW0w@mail.gmail.com> In-Reply-To: <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com> References: <d7621074-acb4-c5b6-1efd-dc55b51586b1@gmail.com> <201803132055.aa28780@berenice.pkmab.se> <CANCZdfoU1B4228RpwfupvdVN9RPCCug4p283xmkNwW7t-M9CjA@mail.gmail.com> <20180313222344.2929E156E812@mail.bitblocks.com> <1f8fc07b-9bf0-f9b2-ae7e-7cb0919722d0@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 13, 2018 at 8:16 PM, Theron Tarigo <theron.tarigo@gmail.com> wr= ote: > 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 descendants. >> >> 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 s= uid > bits for any process with a non-empty mount table should in theory preven= t > exploitation of setuid. Allowing safe setuid in combination with ("trust= ed" > ?) 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 insurmounta= ble > 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 =E2=80=9C FreeBSD needs a proper stacking vf= s ...=E2=80=9D 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 /bi= n to >> the targets /bin . Now expand that to most of the base system and the mo= unt >> tmpfs=E2=80=99s for /tep /var/log etc. most of that works but try to un= mount it in >> the wrong order or thrash a unionfs with lots of writes ,on top of a tmp= fs >> 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 functiona= lly > equivalent to per-process namespace, but would have the very same securit= y > problems as already discussed (as any chroot have) so configuring such > environments would be available only to superuser. I was not thinking of you cobbling nullfs and unionfs into a FreeBSD version of plan9's bind I was thinking more about how nullfs , and unionfs are influenced by plan9 and how they could benefit from someone with some plan9 experience. Not to say that any of the prior work was done poorly or incorrectly because of a lack of plan9 experience . But that your enthusiasm would be better focused on a part of base that could use some polish and maybe some rethinking . > > 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 idea here could be to use capsicum to enforce this requirement but that would be a new approach from what I understand. https://www.freebsd.org/cgi/man.cgi?capsicum(4) > > One thought I had is to do all of this purely in user-space by creating a= n > extension to libc which allows appropriately linked programs to find file= s > 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 th= is > 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 I think there is a lot of opportunity here to pick apart a subsystem that shares some commonality with plan9 . I think that improving unionfs / nullfs to have less edge cases would be a great project. You would need to set a smaller goal for managing the expiation of time you will have for GSoC . Some small tasks that could be a starting point for working on this project. There are a few projects that depend on creating a unionfs of a tmpfs and a readonly disk image. One example would be booting off a CD-Rom and using a unionfs to make a ram disk give the read-only medium the appearance of have a read / write. Second example is the Docker / Container setup where a read-only loop-mounted disk image is unioned to a ram disk in a similar way to the cdrom was before . Third option is where a Jail is created from a template directory that would mount versions of a binary or directory into the jailed environment for various reason. --=20 mark saad | nonesuch@longcount.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMXt9NZyhJFEq0BAwXWXaLb1h0vQHaio-F4whZ6Y789bGsYW0w>