Supplying custom selinux policies in a package

[ctrox]

Hi, I'm trying to get zeropod or more specifically criu to run on bottlerocket and I'm running into some selinux denials. Is it possible to create a package that adds selinux policies? I managed to get everything running by forking bottlerocket-core-kit and adding my policy to packages/selinux-policy/ but I don't really want to maintain that as even just building the core kit is quite heavy.

I found this issue which lead me to believe that it might not be possible but maybe something changed in the meantime?

[ctrox]

One thing that seems to work is just copying packages/selinux-policy into my variation and modify it. It appears to take precedence over the selinux-policy that is in the upstream bottlerocket-core-kit. But would be nice to know if this is a a bad idea for some reason or if there's a better way to do this.

[bcressey]

There are implementation aspects that make downstream customization hard. Bottlerocket's policy is currently written to adds sets of permissions to sets of types, and also to deny sets of permissions to other sets of types. These sets can't be changed downstream and the deny rules can't be relaxed.

The easier case would be to support file labeling only - e.g. a variant could express that /usr/bin/criu needs some existing type runtime_exec_t. But it's unclear how useful that is in the real world; if we have to make permission changes in the policy as well, it's trivial to add another file labeling rule at the same time.

One of the motivations for #128 was to support Kata as a runtime, and there we concluded that it'd be simpler to add support for Kata to the core kit policy.

Ideally we'd just upstream the changes needed for criu to work. If it's invoked via a containerd shim, it should be keeping runtime_t as its type, which is quite privileged. I'm happy to help with this.

In lieu of that, the safest way in terms of alerting you to changes would be a downstream package with:

# Depend on the upstream policy 
BuildRequires: %{_cross_os}selinux-policy
# Shadow the upstream policy after this is built
Provides: %{_cross_os}selinux-policy = 1:

Then copy the CIL files from where they're installed, apply a patch, rebuild the policy, and install the new policy and modules to the build root.

After that you should only need to revisit it when the patch fails to apply because context has changed.

[ctrox]

Thanks for the reply! I would absolutely prefer not having to build a bottlerocket variant as just keeping up with version updates would be quite the hassle.

I actually found a (hacky) way to get criu working on stock bottlerocket. Using a "superpowered" host container I'm able to install my own selinux module using semodule -i. But this existing rule blocked me from giving runtime_t execmem permissions which criu requires:

(neverallow host_s global (processes (relax)))

So this would fail:

(allow runtime_t self (process (execmem)))

I then found super_t, which does not belong to host_s so I can give it all the required permissions and then I simply switch to super_t in my code before calling criu. This works but yeah I would much prefer having this all built-in so runtime_t is allowed to execute criu.

Anyways, here are the added permissions that I think would make criu work with runtime_t:

(allow runtime_t container_t (fifo_file (write)))
(allow runtime_t container_t (process (ptrace)))
(allow runtime_t self (process (execmem)))

Not completely sure if the ptrace one is needed and again, this would currently not compile because of that neverallow rule.

Sidenote: Any thoughts on adding superpowered to bootstrap containers? Would prefer that to host-containers as installing a runtime is a one-shot thing.

[arnaldo2792]

@ctrox , see #4731 (comment) for the current thoughts on superpowered bootstrap containers.