Thanks Daniel. I'm not seeing anything suspicious in the audit logs, the. following are the MAC_POLICY_LOAD events type=SYSCALL msg=audit(1622991228.547:183): arch=c000003e syscall=1 success=yes exit=8577048 a0=4 a1=7fd682c61000 a2=82e018 a3=0 items=0 ppid=62178 pid=62186 auid=1004 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="load_policy" exe="/usr/sbin/load_policy" subj=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 key=(null) type=MAC_POLICY_LOAD msg=audit(1627002776.825:6075): auid=4294967295 ses=4294967295 lsm=selinux res=1 ---- type=MAC_POLICY_LOAD msg=audit(1627008064.852:7615): auid=4294967295 ses=4294967295 lsm=selinux res=1 ---- type=MAC_POLICY_LOAD msg=audit(1627008273.029:7617): auid=4294967295 ses=4294967295 lsm=selinux res=1 ---- type=MAC_POLICY_LOAD msg=audit(1627009159.383:8392): auid=4294967295 ses=4294967295 lsm=selinux res=1 ---- On Thu, Jul 22, 2021 at 2:38 AM Daniel Walsh <dwalsh@xxxxxxxxxx> wrote: > > On 7/21/21 18:17, Sujithra P wrote: > > Thanks Paul! > > > > Is there any specific centos/RH mailing list that I can ask? Not sure > > whether it is a problem with kernel/docker/kubelet. > > semodule -R seems to fix the problem, but not sure what is causing the > > loaded policy to get corrupt. > > Any insight on how to figure this out would be very much appreciated. > > > > Thanks > > Sujithra. > I am guessing that one of the containers is loading policy. You should > be able to see something in the auditlog, about a policy load. > > On Wed, Jul 21, 2021 at 2:01 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > >> On Wed, Jul 21, 2021 at 2:46 PM Sujithra P <sujithrap@xxxxxxxxx> wrote: > >>> Hi SELinux Experts, > >>> > >>> The following issue is described in the below post as well. > >>> https://github.com/containers/container-selinux/issues/141 > >>> > >>> Occasionally running into the following selinux denials for docker > >>> > >>> type=AVC msg=audit(1626732057.636:4583): avc: denied { associate } > >>> for pid=57450 comm="dockerd" name="/" dev="tmpfs" ino=150014 > >>> scontext=system_u:object_r:container_file_t:s0:c263,c914 > >>> tcontext=system_u:object_r:lib_t:s0 tclass=filesystem permissive=0 > >>> > >>> type=AVC msg=audit(1626812823.170:9434): avc: denied { associate } > >>> for pid=20027 comm="dockerd" name="/" dev="tmpfs" ino=198147 > >>> scontext=system_u:object_r:container_file_t:s0:c578,c672 > >>> tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0 > >>> > >>> > >>> level=error msg="Handler for POST > >>> /v1.40/containers/a3a875e7896384e3bff53b8317e91ed4301a13957f42187eb227f28e09bd877c/start > >>> returned error: error setting label on mount source > >>> '/var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/kubernetes.io~secret/secret': > >>> failed to set file label on > >>> /var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/kubernetes.io~secret/secret: > >>> permission denied" > >>> > >>> > >>> Docker is not able to set labels for these tmpfs mounts because they > >>> end up having wrong labels when they are created (sometimes > >>> "locale_t", sometimes "lib_t" which of course is not the > >>> default/correct context for tmpfs fs). > >>> Apparently semodule -R and deleting these tmps files or reboot of the > >>> node fixes the problem. > >>> Not sure what is causing the tmpfs mounts to get wrong labels in the > >>> first place. > >>> > >>> Everything seems to be fine to begin with, but as the system keeps > >>> scheduling pods on the node, this behavior is observed sometimes (not > >>> consistent always). > >>> > >>> > >>> OS Details: > >>> > >>> NAME="CentOS Linux" > >>> VERSION="8 (Core)" > >>> ID="centos" > >>> ID_LIKE="rhel fedora" > >>> VERSION_ID="8" > >>> PLATFORM_ID="platform:el8" > >>> PRETTY_NAME="CentOS Linux 8 (Core)" > >>> > >>> Docker Version: > >>> Client: Docker Engine - Community > >>> Version: 19.03.13 > >>> API version: 1.40 > >>> Go version: go1.13.15 > >>> Git commit: 4484c46d9d > >>> Built: Wed Sep 16 17:02:36 2020 > >>> OS/Arch: linux/amd64 > >>> Experimental: false > >>> > >>> Kubernetes Version* > >>> v1.20.8-gke.1500 > >>> > >>> > >>> Any help on how to debug this issue would be greatly appreciated. > >> This sounds like it might be a problem with CentOS and/or your Docker > >> install, have you tried talking with the RH/CentOS folks about this > >> problem? We focus mostly on upstream issues here and it isn't clear > >> to me at this moment that this is an upstream issue. > >> > >> -- > >> paul moore > >> www.paul-moore.com > >
