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.
