Skip to content
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

Permission denied due to SELinux on /sys/fs/cgroup/cpu/ #582

Closed
matejvasek opened this issue Jan 28, 2021 · 5 comments
Closed

Permission denied due to SELinux on /sys/fs/cgroup/cpu/ #582

matejvasek opened this issue Jan 28, 2021 · 5 comments

Comments

@matejvasek
Copy link

Containers are not able to access /sys/fs/cgroup/cpu/cpu.cfs_quota_us dues to SELinux.

SELinux is preventing run-java.sh from read access on the lnk_file cpu.
 
*****  Plugin catchall (100. confidence) suggests   **************************
 
If you believe that run-java.sh should be allowed read access on the cpu lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'run-java.sh' --raw | audit2allow -M my-runjavash
# semodule -X 300 -i my-runjavash.pp
 
Additional Information:
Source Context                system_u:system_r:container_t:s0:c753,c917
Target Context                unconfined_u:object_r:container_runtime_tmpfs_t:s0
Target Objects                cpu [ lnk_file ]
Source                        run-java.sh
Source Path                   run-java.sh
Port                          <Unknown>
Host                          bellatrix
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.4-55.fc31.noarch
Local Policy RPM              selinux-policy-targeted-3.14.4-55.fc31.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     bellatrix
Platform                      Linux bellatrix 5.8.18-100.fc31.x86_64 containers/podman#1 SMP Mon
                              Nov 2 20:32:55 UTC 2020 x86_64 x86_64
Alert Count                   36
First Seen                    2021-01-28 17:25:28 CET
Last Seen                     2021-01-28 18:03:31 CET
Local ID                      5422b468-46fc-4776-9efb-36eb8b33f3d0
 
Raw Audit Messages
type=AVC msg=audit(1611853411.946:10554): avc:  denied  { read } for  pid=2463591 comm="run-java.sh" name="cpu" dev="tmpfs" ino=38477749 scontext=system_u:system_r:container_t:s0:c753,c917 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=lnk_file permissive=0
 
 
Hash: run-java.sh,container_t,container_runtime_tmpfs_t,lnk_file,read

This was introduced in containers/podman#8949.

To reproduce try run podman run -it --rm docker.io/library/alpine:latest cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

You need to run cgroups v1 (not v2).

@matejvasek
Copy link
Author

/cc @rhatdan

@matejvasek
Copy link
Author

/cc @giuseppe

@rhatdan
Copy link
Member

rhatdan commented Jan 28, 2021

@giuseppe This looks like some files/directories are being created by podman/crun in /run or /tmp or /dev/shm and being mounted into the container. Is there some tool creating the /sys directory on a tmpfs?

type=AVC msg=audit(1611853411.946:10554): avc: denied { read } for pid=2463591 comm="run-java.sh" name="cpu" dev="tmpfs" ino=38477749 scontext=system_u:system_r:container_t:s0:c753,c917 tcontext=unconfined_u:object_r:container_runtime_tmpfs_t:s0 tclass=lnk_file permissive=0

The container_runtime_tmpfs_t is the label that podman or any container engine would create when writing to a tmpfs (tmpfs_t).
The container is trying to read a lnk_file named "cpu"

@giuseppe giuseppe transferred this issue from containers/podman Jan 29, 2021
@giuseppe
Copy link
Member

can you please give more details on the components you've used? What is the version of crun you are using?

I can reproduce the issue with crun 0.15, but it was fixed with #531 and crun 0.15.1 has the fix

@matejvasek
Copy link
Author

I can confirm the bug is reproducible on 0.15, with 0.17 it works all right. Thanks @giuseppe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants