Created attachment 982234 [details] warnings Running a server under docker leads to warnings from selinux that I believe are not reasonable. I use docker to test a server's operation, and selinux warns that the server uses setrlimit(), and accesses a tun device it has created. I would have expected normal operation as everything done was within the container and the server had the appropriate permissions for them (was run as root). The script I use to reproduce (it will require compiling the server in the same repository): http://git.infradead.org/ocserv.git/blob/HEAD:/tests/full-test
8786aeed2169b2e5e33ec061ae259ca2d3fb0a49 allows docker_t to setrlimit. Where is ocserv-socket.32 located? Why is docker trying to write to it?
(In reply to Daniel Walsh from comment #1) > 8786aeed2169b2e5e33ec061ae259ca2d3fb0a49 allows docker_t to setrlimit. Thanks. > Where is ocserv-socket.32 located? In /var/run > Why is docker trying to write to it? It's a socket created by the server and used for IPC afterwards.
Well it is labeled unlabeled_t which is very strange. This file looks like it has a bad label on it. When you say IPC, what kind of IPC? Did you change docker to communicate with it for some reason?
The communication is within docker only. I didn't change docker in any way. The IPC used is messages over a unix socket file. The security module process creates the socket file, and the worker processes open it, and write messages to it.
What backend are you using? Is this Overlayfs?
(In reply to Daniel Walsh from comment #5) > What backend are you using? Is this Overlayfs? I didn't use anything special than the default in f21.
Thats wierd, since I have never seen this one from anyone else. Does the container work?
Has anyone else run a server using unix socket files under fedora's docker? The container works, but I cannot understand the type of policy applied there. The log mentions "Enforcing Mode Enforcing", while the raw audit message has "permissive=1" The issue is reproducible by simply downloading the server, compiling and running the full-test script in Fedora.
The problem is we see an unlabeled_t socket show up inside of a container. This means the socket either has a label the kernel does not understand or it has no label at all. These types of files should not be on a normal system. And I have never seen a socket with that name.
This particular test, creates a container with certain libraries, and copies from the host OS the compiled server binary to the container. Then the copied server is executed within the container. Could that cause the mislabel?
No, mv from an unlabeled file could cause a mislabel, but cp should not. Unless you are using some kind of preserve to preserve the bad label.
I was referring to the docker ADD command. Not sure whether it translates to cp.
Ok so this was during a docker build. There is some fixes for SELinux coming in docker-1.5, which might fix the problem. This should be released early next week.
selinux-policy-3.13.1-105.6.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-105.6.fc21
Package selinux-policy-3.13.1-105.6.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-105.6.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-3476/selinux-policy-3.13.1-105.6.fc21 then log in and leave karma (feedback).
selinux-policy-3.13.1-105.6.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.