On Thu, Jan 2, 2025 at 11:45 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > This is an RFC-only for the SELinux namespace support, just to > encourage early review and identification of any show-stoppers > with respect to the design and implementation to date. > Patches 0001 through 0009 are just re-based versions of the original > SELinux namespace series that predated COVID. The remaining patches > are all new relative to mid-2024 when work on the namespace > support restarted. > > If you actually want to try running it, I'd recommend instead using > my branch which has an additional cherry-picked fix from upstream > needed to avoid crashing the kernel. This can be cloned via > git clone -b working-selinuxns \ > https://github.com/stephensmalley/selinux-kernel > > Configure the kernel as usual but add CONFIG_SECURITY_SELINUX_NS=y > to enable the support. More detailed instructions on building, booting, > and testing the SELinux namespace support available upon request. I > have been running the SELinux testsuite and booting Fedora, > Rocky 9, and Rocky 8 containers with SELinux enforcing within > the container on a Fedora SELinux-enforcing host OS, a Fedora > SELinux-disabled (no policy) host, and an Ubuntu SELinux-disabled > (no policy) host. > > Known remaining issues include: > - Per-namespace checking of all relevant policy capabilities (currently > done for the open_perms capability), > - Proper handling of peer/packet labels when they cross SELinux namespaces, > - Optimizing the implementation for the single SELinux namespace case, > - Review, and if desired, change the kernel interface for unsharing the > SELinux namespace (currently via /sys/fs/selinux/unshare with a > libselinux wrapper), > - Namespace-aware context mount options for sVirt-like setups, > - Namespace support for certain residual networking hooks that lack it > - Anything else noted in the patches themselves. > > It is an open question as to whether some or all of the changes could > be merged before all of the above issues are resolved, given that > the support is only exposed to userspace if CONFIG_SECURITY_SELINUX_NS=y > and even then only to privileged userspace. I think at a minimum we > would likely need to optimize the implementation for the single SELinux > namespace case so that it does not introduce any significant overhead > prior to merging, or extend CONFIG_SECURITY_SELINUX_NS to actually > compile away the extra storage and runtime overheads introduced by > the infrastructure. Open to suggestions. For those following along, I have created a repo with a README.md capturing instructions for how to build and use this support along with open issues for the known remaining work items here, https://github.com/stephensmalley/selinuxns Also, I addressed a couple of comments I received, squashed a few commits together where it didn't make sense to keep them separate, and re-based on latest selinux/dev.
