At Wed, 20 May 2020 09:43:12 -0400, "Aaron B." <aaron%zadzmo.org@localhost> wrote: Subject: Re: NetBSD Jails > > For the purpose of isolation of applications, I'd like to segment the > process tree in the same way that chroot segments the filesystem tree. > I don't necessarily need a "root" user inside these segments. > > Semantics similar to chroot, wherein a parent process calls the > appropriate system call and from that point forward can only interact > with it's child processes - which inherit the same segment - would be > perfect. I think this is easily solvable without adding any ugly new bits to NetBSD -- i.e. by just enhancing existing features. So, chroot already provides the isolation of a process tree within filesystem space naturally -- that's exactly what it's designed to do. > And yes, I have looked into curtain mode. It's interesting but does not > do this. Well if all your chroot tree of processes runs as a single unique user then from what I understand secmodel_extensions "Curtain Mode" already does actually do all of the rest of what you need. To also limit a chrooted process tree to seeing and interacting with just the processes that were started from the "chroot" process even if some of them use setuid seems to me to be, conceptually speaking at least, to be a relatively simple extension to Curtain Mode. (An extremely simple extension compared to trying to import FreeBSD Jails.) The tricky part might be in how to have shared filesystem that underlies a vast number of chrooted services, _and_ which allows setuid to be used within but in such a way that each chrooted process runs as a unique ID when it execs a setuid binary but that new unique ID maps back to provide appropriate access to the filesystem as necessary. Here again it seems that, conceptually at least, secmodel(9) and secmodel_extensions(9) in particular is the right approach, especially given that secmodel already permeates the kernel in probably all the necessary places. Defining the semantics and getting it right may also require the help of ACLs (which we don't quite yet have, but perhaps very soon), perhaps with some minor enhancement of ACLs to also support mapping to a unique IDs associated with a chroot. So, is it necessary to support setuid binaries in a shared filesystem used to underly chrooted processes? In the mean time one could argue "disk is cheap" and say that every chrooted service gets its own copy of the file tree. Alternatively there is also the secmodel_extensions(9) "Non-superuser mounts" which could allow for a chrooted service to share most of its file tree, but for each to mount their own unique sub-tree with uniquely setuid binaries, etc. in it. They could also share this sub-tree of setuid binaries but mount it with mount_umap(8) so that they see each setuid binaries with their own per-chroot unique UIDs. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp5rVZ_RXkWM.pgp
Description: OpenPGP Digital Signature