SELinux blocks fanotify_mark from a Pod that has super_t type about bottlerocket HOT 3 OPEN

privileged: true currently has the effect of silently overriding any custom SELinux label. The workaround is to not set it, but to enable all capabilities, disable seccomp, etc, to gain most of the effects of privileged: true without actually setting it.

from bottlerocket.

Thanks @bcressey , it works indeed when removing privilged: true.

We have tried both control_t and super_t, does it make sense that only the later works?

from bottlerocket.

@slashben these actions are currently restricted to super_t, which is meant to be a deliberate opt-in to system calls that can break host functionality in surprising ways.

In this case it's that a process using restrictive fanotify access logic on host mounts can block the API from working, block the flow of container metrics, prevent updates from being applied, etc.

SELinux relabeling is also restricted to super_t for essentially the same reason.

"Can it prevent updates, brick the node on update, or cause data loss after an update?" is the key question. Of course most uses of fanotify (and most uses of SELinux relabeling) are not going to have this effect, but some can.

The opt-in is partly to acknowledge the risk and partly so we know when troubleshooting something that the usual rules may not apply.

from bottlerocket.