Use cases where file blocking might be required

[lrishi]

Hello everyone!
I'd like to understand a bit more about the reasons behind imposing this specific selinux policy:

; No components are allowed to block access to files by using
; fanotify permission events. Fanotify only sends events for
; accesses from within the mount namespace, so it's unlikely to
; be useful for containers, and we don't use it in the host.
(neverallow all_s global (files (block)))

There are usecases where fanotify perm events are particularly useful in trapping file accesses within the container, especially when allowing execution of only known binaries. Is there any specific reason this has to be disabled? If not, it'll be great to enable it!

[bcressey]

There are usecases where fanotify perm events are particularly useful in trapping file accesses within the container, especially when allowing execution of only known binaries. Is there any specific reason this has to be disabled? If not, it'll be great to enable it!

As a quick bit of terminology - Bottlerocket's SELinux policy refers to "subjects" (labeled processes) and "objects" (labeled inodes).

To allow containers to use the "watch_with_perm" action - which is the fanotify mode that supports permission checks and blocking access - we'd need to write a rule like:

; Allow container subjects to block access to constrained objects.
(allow container_s constrained_o (files (block)))

The reason why a rule like this has never been added is that it's not scoped to just containers. Since there's no way to refer to the subject label of the process attempting access, this rule would allow any container to block any process from accessing those files, even host components (like runc and containerd) that expect to be able to fully manage the lifecycle of that content.

What I'd really prefer is a set of rules like:

1. containers can't block host access to any files
2. unprivileged containers can only block access to their own files, not files for other unprivileged containers
3. privileged containers can block access to files for all containers

Since the time I wrote that comment in a5e8a59, Bottlerocket has added support for MCS constraints, which allows for more fine-grained restrictions.

MCS constraints allow for (2) and (3), but not (1) as far as I know. That's because the SELinux check applies when the watch is added, rather than when the access is attempted, so there's no useful information about the subject available.

I'm tentatively willing to try an implementation that doesn't satisfy (1), but it would need some careful testing to ensure that an unprivileged container can't prevent kubelet from running health checks, or containerd from calculating disk usage - or at least, that the result of such misbehavior is "pod gets evicted" rather than "node suffers denial-of-service".

[bcressey]

From that same commit message:

However, fanotify doesn't deliver events for accesses from outside the mount namespace, so it's unlikely that containers depend on this functionality.

Assuming this is correct - as I clearly believed at one point - that would satisfy all three properties, since host processes are necessarily running in a different mount namespace from any container, and containers are also in different mount namespaces.

I asked a kernel engineer about this behavior at the time and we concluded that it might be an accident or oversight, and that the events should actually be delivered. If it's really intentional and part of the overall fanotify "contract" then that makes things easier.

[lrishi]

@bcressey Thanks for your response, and apologies for the delay in getting back. We have usecases in security domain where a small utility runs inside the protected container (by a predefined security policy) and process blocking fanotify events. It'll be great to have privileged containers the access to place blocking fanotify marks.