At Wed, 20 May 2020 09:43:12 -0400, "Aaron B." <aa...@zadzmo.org> 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 <gwo...@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
pgpSc_eApGMzi.pgp
Description: OpenPGP Digital Signature
