On Mon, Oct 28, 2024 at 8:38 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Sat, Oct 26, 2024 at 2:29 AM C.J. Collier <cjac@xxxxxxxxxxxxxxx> wrote: > > > > Hi Stephen, > > > > I'd be interested in testing this new code. Are there any tips or tools for spinning up a qemu environment with a kernel patched to include the changes? Where can I find your test suite? > > > > I presume that you're targeting RHEL/Fedora. I'd be interested in exercising the Debian use case. > > > > Is there an irc channel? > > > > Russell, do you have any tips? > > > > Most of my customers are Hadoop users. > > > > Thanks for your persistence here, Stephen. I've been watching with interest since August. > > Thanks for offering to test, but be warned that there is a bit of a > high bar to doing so. > > At present, one has to clone, build, and boot the working-selinuxns > branch of my selinux-kernel fork: > git clone -b working-selinuxns > https://github.com/stephensmalley/selinux-kernel > with CONFIG_SECURITY_SELINUX_NS=y set in the kernel configuration. > The _MAXNS and _MAXNSDEPTH configuration options can either be left > with their default values or, > if you want to prevent child namespaces from creating their own nested > SELinux namespaces beyond > the one they are given, you could set CONFIG_SECURITY_SELINUX_MAXNSDEPTH to 1 or > "echo 1 > /sys/fs/selinux/maxnsdepth" at runtime. > > To exercise the functionality in containers, I have sample patches for > libselinux to wrap the kernel interface on the selinuxns branch of my > selinux fork: > git clone -b selinuxns https://github.com/stephensmalley/selinux > and patches for systemd-nspawn and systemd on the selinuxns branch of > my systemd fork: > git clone -b selinuxns https://github.com/stephensmalley/systemd > > You'd most likely want to cherry-pick the patches over to whatever > versions of libselinux and systemd your distro is using. > > As far as testing goes, to date that has consisted of running the > existing selinux-testsuite in the init SELinux namespace > and in a manually unshared child SELinux namespace to ensure no > regressions, with some patches to the testsuite for > corner cases in the selinuxns branch of my selinux-testsuite fork: > git clone -b selinuxns https://github.com/stephensmalley/selinux-testsuite > > And using the patched systemd-nspawn to spawn a container with its own > SELinux namespace via the new --selinux-namespace option, > with the patched systemd inside the container so that it will proceed > to load its own policy and set its own enforcing mode based on the > container's > configuration, independent of the host OS. For the latter, I've only > tested Fedora containers on a Fedora host thus far. Some policy tweaks > are required to make this work in enforcing mode but that's relatively > straightforward based on the logs when run in permissive mode. > > Sorry, no irc channel specifically for this and I'm not generally on > the existing selinux irc channels due to limitations associated with > my workplace. > > Happy to send more detailed instructions and answer questions by email > off-list if you are still interested. Status update for those who are following along and/or interested in trying it themselves and/or interested in helping: - I have successfully booted Fedora, Rocky 9, and Rocky 8 with SELinux enforcing in containers with their own SELinux namespace on a Fedora host with SELinux enforcing. The purpose of trying Rocky 9 and Rocky 8 was to exercise distro releases with increasingly older policies and userspace. No obvious problems manifested although admittedly I didn't do much more than boot, login, and look around a bit. - I have done the same on a Fedora host OS with no policy loaded (the closest to SELinux-disabled on the host that can still support SELinux namespaces for the containers). That triggered a kernel bug that I have now fixed, required some further policy customizations for the containers due to differences in the labeling (or lack thereof) on the host, and required relabeling the container filesystem on first boot, but otherwise seemed to work. - I have done the same on an Ubuntu host OS, again with SELinux enabled but no policy loaded on the host itself. This worked identically to the previous case (in fact even used the exact same container images for Fedora and Rocky 8 and 9). There are still a number of known issues still to be resolved to make the SELinux namespaces fully safe (but access from userspace is protected behind a kernel config option + a new SELinux unshare permission + root/CAP_DAC_OVERRIDE to write to the selinuxfs unshare interface + the ability to limit the depth and number of namespaces so that e.g. containers can't further unshare/nest namespaces), and I haven't yet looked at performance overheads, but I'm wondering if it makes sense to post the latest patch series for review / discussion? Or something else to get a bit more feedback / engagement?
