At Thu, 21 May 2020 00:17:27 -0400, "Aaron B." <aaron%zadzmo.org@localhost> wrote: Subject: Re: NetBSD Jails > > On Wed, 20 May 2020 14:47:52 -0700 > "Greg A. Woods" <woods%planix.com@localhost> 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 <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:
pgpxYJ9kdX9Je.pgp
Description: OpenPGP Digital Signature