SELinux Policy: system_u:system_r:cachefiles_kernel_t:s0

[woehrl01]

What I'd like:
I would like to enable fscache in order to allow caching of NFS files. Currently my issue is that on running cachefilesd I either receive:

About to bind cache
CacheFiles bind failed: errno 13 (Permission denied)

or

About to bind cache
CacheFiles bind failed: errno 22 (Invalid argument)

The last happens if I specify, which should be the correct selinux policy to reference

secctx system_u:system_r:cachefiles_kernel_t:s0

It looks like the policy is missing in bottlerocket os:

[root@admin]# seinfo -t | grep cache
   cache_t

I appreciate if that policy could be added.

Related links:

• https://bugzilla.redhat.com/show_bug.cgi?id=841425

Any alternatives you've considered:

[koooosh]

Hello, thanks for submitting this feature request!

I've confirmed that Bottlerocket currently does not have this policy:

• I searched the Core-kit repo selinux-policy package and found no results
• I verified on a Bottlerocket instance:
  • AMI: bottlerocket-aws-k8s-1.24-x86_64-v1.20.2-536d69d0
  • Steps:
    1. SSM into the instance and enter the admin container
    2. yum install setools-console to install seinfo

[root@admin]# seinfo -t | grep cache
   cache_t

We will discuss within the team if it's viable to add this policy and will get back to you with the decision.

[arnaldo2792]

I've been playing around with this, and I found a few things, but first some clarifications for others that find this issue:

It looks like the policy is missing in bottlerocket os

By default, the cachefilesd package will configure cachefiles_kernel_t as the SELinux context in /etc/cachefilesd.conf. You can skip this by commenting the line as follows:

# secctx system_u:system_r:cachefiles_kernel_t:s0

That will force the process to use the parent's SELinux context. The Bottlerocket SELinux policy is way different than the refpolicy which is what this project assumes is available in the host and therefore attempts to set the "standard" label for cachefilesd. This SELinux context isn't necessary as long as you use the correct SELinux context with the correct privilege, and with this lets move to my findings.

I first loaded the cachefiles kernel module, just as the systemd service for cachefilesd does:

modprobe -qab cachefiles

Then, I deployed a pod with the following spec:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fedora
spec:
  selector:
    matchLabels:
      name: fedora
  template:
    metadata:
      labels:
        name: fedora
    spec:
      containers:
        - name: fedora
          image: fedora
          command: ["sleep", "infinity"]
          securityContext:
            privileged: true
          # These will be accessed by cachefilesd
          volumeMounts:
            - mountPath: /dev/log
              name: journal
              readOnly: false
            - mountPath: /dev/cachefiles
              name: cache
              readOnly: false
      volumes:
        - name: journal
          hostPath:
            path: /dev/log
        - name: cache
          hostPath:
            path: /dev/cachefiles

This got me to pass SELinux problems, but I keep getting this error:

CacheFiles bind failed: errno 95 (Operation not supported)

But no AVC denials, I wonder if we are missing a kernel config to allow this, or if control_t isn't enough and this actually requires more privilege.