SELinux policy prevents pods from watching the journal

[bcressey]

Image I'm using:
aws-k8s-1.17 v1.0.1

What I expected to happen:
To be able to collect journal logs from a pod.

What actually happened:

[1528285.589266] audit: type=1400 audit(1601383563.515:8): avc: denied { watch } for pid=668607 comm="event_loop" path="/var/log/journal/ec23ab7a8286d713d41887457658cfc6" dev="nvme1n1p1" ino=261640 scontext=system_u:system_r:container_t:s0 tcontext=system_u:object_r:state_t:s0 tclass=dir permissive=0

$ cat /proc/668607/cmdline
/usr/local/bin/ruby-Eascii-8bit:ascii-8bit/fluentd/vendor/bundle/ruby/2.6.0/bin/fluentd-c/fluentd/etc/fluent.conf-p/fluentd/plugins--gemfile/fluentd/Gemfile--under-supervisor

How to reproduce the problem:
Deploy the agent for Cloudwatch Container Insights:
/~https://github.com/aws-samples/amazon-cloudwatch-container-insights

[Niksko]

Using control_t lets the container watch, but presumably that's not ideal? Is there another type that's better suited or that we could create?

[bcressey]

Using control_t lets the container watch, but presumably that's not ideal? Is there another type that's better suited or that we could create?

control_t is reasonable, though it's not least privilege since it also allows use of the host's API socket.

The primary reason watches are restricted is to prevent fanotify from being used to block the host's access to its own files by denying the permission check. It should be OK to relax the policy so it only blocks these watch_with_perm actions.

The other benefit of restricting watches is to prevent pods from depending on the existence of specific directories or files in the host OS, which could change in an incompatible way across an upgrade. But this isn't as important and doesn't actually make sense in cases like this where we want pods to be able to collect host logs.