selinux: Docs state it works, but issue tracker does not corroborate

[stephen-fox]

The Flatcar Linux website states that SELinux is not enforcing by default and that it can be set to enforcing if desired:

Flatcar Container Linux implements SELinux, but currently does not enforce SELinux protections by default. This allows deployers to verify container operation before enabling SELinux enforcement. This document covers the process of checking containers for SELinux policy compatibility, and switching SELinux into enforcing mode.SELinux into enforcing mode.

• https://www.flatcar.org/docs/latest/setup/security/selinux/

Based on discussions with @JAORMX and several open GitHub issues, it sounds like SELinux does not work properly or does not work at all. For example:

• [RFE] new package: sec-policy/selinux-container #479
• SELinux prevents usage of execsnoop in enforcing mode #509
• [RFE/Fix]: Smooth out SELinux rough edges in Flatcar #673
• getting "avc: denied" messages in system logs  #696
• build_sysext: Add SELinux labeling #1147

A clear answer about Flatcar's support for SELinux in its documentation would be deeply appreciated.

Impact

SELinux is an important building block for the overall security of a Linux machine. It also provides an additional meaningful layer of security for the OS by limiting the blast radius of container escapes. Users of Flatcar Linux should be provided a clear description of the operating system's support for SELinux.

Environment and steps to reproduce

N/A

Expected behavior

Either of the following:

• SELinux is enforcing by default without any special work-arounds or exceptions
• Alternatively: The documentation clearly states that SELinux is not currently supported. Perhaps optionally provide a URL to an "umbrella" issue or GitHub milestone tracking the progress towards implementing SELinux

[tormath1]

Hello @stephen-fox and thanks for your issue. From a historical perspective, it seems that SELinux support was initially implemented only for containers running on the OS. For example, if you run a container its process will be correctly labelled:

$ docker run -d alpine sleep infinity
$ ps auxZ | grep sleep
system_u:system_r:svirt_lxc_net_t:s0:c484,c705 root 1228 0.0  0.0 1588 4 ? Ss   07:09   0:00 sleep infinity

I think that was the main purpose initially.

Two things:

• The issues linked above are mainly caused by missing rules from the current policies: recent software require new permissions which are shipped in new policies. This is in progress and under review in this PR: selinux: update scripts#917
• About the relabeling of the whole system, we might wait for the Torcx deprecation to continue investing in this direction (https://github.com/flatcar/Flatcar/milestone/5)

FWIW, with ~120 automated tests there are ~10 tests that do not run in enforcing mode.

Note: Regarding the umbrella issue, it's this one: #673

[JAORMX]

Maybe a better description is that it doesn't properly work for k8s?

[stephen-fox]

If I am following along properly @tormath1, it sounds like executing a containerized process via certain tools (like docker) results in a correctly-labeled process. However to @JAORMX 's point in issue #673, other programs included with the OS (such as those in /usr/bin) are not labeled at all.

I guess we need to define what "working" means for SELinux to be truly supported. I am concerned that the current default behavior of not enforcing and the documentation stating that SELinux is supported leads to poor assumptions being made by users.

What should I say to someone who is interested in Flatcar, but has an application whose security model heavily relies on SELinux? If neither of us are SELinux experts, how would we safely assess that Flatcar fulfills the application's security model requirements?

[jhaprins]

I think it is very important that selinux is not only working correctly, but also that the correct tools are available to both identify selinux problems and options to fix them.