-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
containerd: SElinux Relabelling broken for Kubernetes volume mounts #1138
Comments
Thanks for the detailed report! Just noting down here the differences in package set between
|
In the container-selinux upstream repo I see:
So maybe containers/container-selinux@cf3da79 is the cause for the change in behavior. I'll have to dig in more tomorrow. Two other notes:
|
I can arrange something like that but hopefully QEMU based virtual lab should suffice? |
It should :) - Obviously a test environment as close to your production environment as possible will give you the best test results, but in the real world that can be hard to come by. In general a virtual lab should give you a good amount of coverage. |
hey @log1cb0mb. I'm trying to figure out what is going on. I started up a node on
In each case the files were dumbly created using If you can reliably reproduce the issue (i.e. install node, working fine, upgrade, not working + AVC denials) it might be worth us inspecting Also - it's always a plus if we could boil this down into a reproducer that doesn't require a kubernetes cluster (single container, just file manipulation). |
@dustymabe think I have found the difference between two versions and context labels. Working node:
Non-working node:
As can be seen, It seems, this is not exactly CoreOS SElinux policy change issue but instead kubelet not labelling directories/files correctly. Note that the Based on actual container inspection,
Now not sure why relabel flag is not working. I am suspecting this has something to do with UPDATE: tried |
Allright confirmed, it is indeed
|
@log1cb0mb - great work tracking that down! Any chance there is an upstream |
Cannot seem to find any similar issue reported so I am going to open one. |
New information: containerd/containerd#6767 (comment) So maybe the issue is related to opencontainers/selinux needing an update. I pinged in the BZ requesting the release bump. And then I think containerd (maybe) would need to get rebuilt? cc @olivierlemasle. |
I am building containerd with the fix (opencontainers/selinux#173) as we speak to test if it indeed helps. Update: It worked! built containerd with these changes: containerd/containerd@768af24 |
@dustymabe Once this is merged: containerd/containerd#6865 |
@log1cb0mb - we'd need to get that backported to the Fedora RPM (@olivierlemasle is the maintainer). |
If we can't get up with him here then opening a BZ against containerd would be the avenue to take. |
@dustymabe will this Bug 2079779 do? |
Yep. That should do! The fix landed upstream in containerd/containerd@cb84b5a |
@dustymabe As packages are now available, I have been trying to find a way how to upgrade containerd in existing release. Is that even possible or does it have to be included in upcoming releases? |
You can grab it from https://koji.fedoraproject.org/koji/buildinfo?buildID=1965128 then |
Hey @log1cb0mb can you try out the latest |
@dustymabe Just tested the build and it is fixed. 👍🏻 |
The fix for this went into |
Tested and fixed. |
Another similar report is at #1211 (comment), also confirmed fixed in |
The fix for this went into |
Issue:
Default SElinux permissions seem to have changed between previous release v35.20220213.3.0 and v35.20220227.3.0.
Kubelet is being denied to access/write under default
/var/lib/kubelet
directory. Issue noticed specifically for container volume mounts under/var/lib/kubelet/pods
which is by default labeled assystem_u:object_r:var_lib_t:s0
, with latest releasecontainer_t
is no longer allowed to accessvar_lib_t
.Reference audit logs for coredns pod:
Mar 22 12:28:49 dc1-worker1.k8s.lab audit[4455]: AVC avc: denied { read } for pid=4455 comm="coredns" name="Corefile" dev="vda4" ino=9438676 scontext=system_u:system_r:container_t:s0:c666,c775 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0
Reproduction steps
Steps to reproduce the behavior:
/var/lib/kubelet
with default SElinux context labels (Not relabeled which obviously fixes the issue)Expected behavior
Kubelet is able to create required volume mounts or any other content under
/var/lib/kubelet/*
. Additionally with SElinux relabeling feature in use for Kubelet, it should be allowed to not only create content under said directory but also relabel for e.g volume mount with respective container SElinux context labels.Actual behavior
container_t
processes no longer allowed to accessvar_lib_t
. labeled directories/files.System details
Additional information
Already tested same behavior with previous v35.20220213.3.0 release and expected behavior is observed. So far I am unable to find any reference if this is an intended behavior and it is known that default permissions have been changed. Could it be that default permissions have been more tightened, removing such access and requires proper relabeling or explicit SElinux policy?
Note: Issue can also be fixed by restoring context labels:
sudo restorecon -R -v /var/lib/kubelet/
OR if Kubelet is running as a container then/var/lib/kubelet
volume mount can be set with:z
flag to relabel the whole directory which is not ideal from security pov and specifically bad idea for large sized persistent volumes etc.The text was updated successfully, but these errors were encountered: