How We Built SELinux Support for Kubernetes

I&#x27;ve written a bunch of SELinux policy, also without being especially expert. The tooling is definitely getting better, but still there are many annoying things from the obscure file layout, the giant all-in-one everything-is-a-global policy[1], to the small annoyances like m4 in the policy files.<p>Of course you need to buy into the whole premise of SELinux - that in addition to simple Unix permissions you can use mandatory access control to fine-grain control everything that a process can do and get access to. Obviously this is a giant boil-the-ocean project that has consumed many good people for decades. For SVirt (secure virtualization) this was pretty successful, allowing many qemu instances to run on a single server, and confining them with SELinux so each can only access its own files even when they are all running as the same Unix user.<p>The linked article is a good intro.<p>[1] But they&#x27;re fixing this, yay! I can&#x27;t find a link now but there&#x27;s a project to decentralise SELinux policy. Perhaps it&#x27;s still an internal-only Red Hat project.

While the article shows how they build SELinux policy from scrath, they also mention udica tool[1] which generates SELinux profile based on container inspection:<p># podman inspect my_container_id | udica my_container<p>I wonder how much would the result be different in their case or how much time would they save by having the first version of the policy being generated this way instead of writing it from scratch.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;udica" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;udica</a>

What&#x27;s the point of SELinux support in a k8s environment, where services are already sandboxed by the container runtime?<p>It&#x27;s unsafe to run untrusted workloads in the host kernel using only namespaces - SELinux does not change this, no matter how much Red Hat wants it to be true. The kernel has a massive attack surface. For untrusted workloads, you need virtualization like gVisor or Kata&#x2F;Firecracker which isolates workloads from the host kernel.<p>SELinux can mitigate some logic bugs in the container runtime, yes, but it doesn&#x27;t make your containers secure.<p>Also, the title of this submission on HN is inaccurate - Gravitational did not build SELinux support for k8s. Red Hat did, a long time ago. They added support for SELinux to their own product, Gravity.

An off-topic but somewhat related question. What is a good way to whitelist which applications can access the network on my desktop linux system? (Currently running Arch, but I distro-hop quite often). Years ago when I had a MacBook, I used a program called Little Snitch. I see that there is a similar application for Linux called OpenSnitch, but I’m hoping there is a better way to utilize the built in features of Linux rather than introducing a 3rd party kernel module. Are SELinux &#x2F; AppArmor the answer? Cgroups? Something else?

SELinux was a good way of securing linux machines with many services sharing things like file systems and binaries.<p>k8s solves this in a different way. You can write applications that are completely stateless when spun up on a k8s node and can be limited to a read only file system. Your container can be a scratch container with no other executables binaries.<p>I don&#x27;t know what their product is, but i seriously doubt mixing these two concepts is the right thing to do.

NSA made SELinux. My theory is that they made it so hard to use so nobody would use it &#x2F;s

Tools write selinux policies, humans write apparmor policies .