NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD Jails

At Thu, 21 May 2020 00:17:27 -0400, "Aaron B." <> wrote:
Subject: Re: NetBSD Jails
> On Wed, 20 May 2020 14:47:52 -0700
> "Greg A. Woods" <> wrote:
> > 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.
> >
> Curtain mode does not.

I think you may have misunderstood what I meant by "tree of processes
runs as a single _unique_ user".  I mean "unique from any other user
running any other process on the system, chrooted or not";
i.e. absolutely unique to that chroot instance and that one alone.

> Some applications run as multiple processes with multiple users, by
> design. Curtain mode as I understand it would tear these apart.

So, that's covered by the rest of my discussion and depends on exactly
how those multiple users get their credentials, and exactly what they
need to be able to do and not do with their different IDs.

1. You have a master control process that runs as root and does the
chroot() and then forks a number of processes each of which then calls
setuid() as necessary before execing each application process that runs
together in the chroot instance.

2. You have a program or script that calls chroot(8) (or its moral
equivalent) and starts your application which then sometimes has to use
enhanced privileges and to do so it forks and execs a setuid binary
within the chroot area, and note this will not be for superuser privs,
but just some other application user.

In both cases there may need to be per-chroot assigned UIDs.

The "disk is cheap" comment was meant to suggest that each chroot area
be a unique stand-alone sub-directory and thus each per-chroot instance
gets its own unique new UIDs assigned at the time it is first created.

If such a scheme requires too much disk space then that's where the
option of using mount_umap(8) (perhaps via non-superuser mounts) might
solve the problem by sharing a single copy of the application storage
directory but presenting unique ownerships (including for setuid
binaries) to each chroot instance.

However, still, in _all_ of these cases I think curtain mode should
still provide all of the extra process and (non-network) resource
isolation necessary between each chroot instance (where normal per-user
controls and limits will still provide the foundations for controlling
the process(es) within the chroot).

If this is not true for you then perhaps you could be very specific
about exactly what a chrooted process running as a unique user-ID, and
behind a secmodel curtain, can still do that you don't want it to be
able to do?

> In addition, if I'm reading the documentation correctly - multiple
> instances of the same application- or any two applications sharing the
> same UID - would be able to interact. That is not isolation.

Obviously -- even FreeBSD Jails do not really offer that kind of totally
secure isolation (it's quite a bit better, I think, but not total, and
that's also why it has to spread its tendrils in an ugly and (arguably)
unmaintainable way throughout the whole FreeBSD kernel).

> > So, is it necessary to support setuid binaries in a shared filesystem
> > used to underly chrooted processes?
> >
> For my specific use case, I don't think so. Processes are launched from
> an external command that calls chroot, then switches to an unprivileged
> UID as needed, then calls exec.

Then you wouldn't/couldn't have multiple processes with different UIDs
in any individual chroot instance, unless it's actually more like what I
described in #1 above where it starts several processes and at least one
or more of them runs as a different UID than the others.

					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpxYJ9kdX9Je.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index