Description of problem: When docker.service is started or when docker run uses -p option, AVC denial is logged. Version-Release number of selected component (if applicable): docker-1.8.2-1.gitf1db8f2.fc22.x86_64 docker-selinux-1.8.2-1.gitf1db8f2.fc22.x86_64 selinux-policy-3.13.1-128.13.fc22.noarch How reproducible: Happening often, even if not 100% deterministic. Steps to Reproduce: 1. dnf install -y docker 2. service docker start 3. docker run -ti -p 80:80 fedora:22 bash Actual results: AVC denial avc: denied { read } for pid=12032 comm="iptables" path="net:[4026531957]" dev="nsfs" ino=4026531957 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 Expected results: No AVC denial. Additional info:
This seems like an SELinux issue. iptables has nothing to do with containers, other then working with the docker daemon. Kernel guys any idea what net:[4026531957] file is? And why it is unlabeled_t?
(In reply to Daniel Walsh from comment #2) > > Kernel guys any idea what net:[4026531957] file is? I can see it as "target" of /proc/1/ns/net symlink and of many other processes, including the docker process.
ps -eZ | grep unlabeled_t
(In reply to Jan Pazdziora from comment #3) > (In reply to Daniel Walsh from comment #2) > > > > Kernel guys any idea what net:[4026531957] file is? > > I can see it as "target" of /proc/1/ns/net symlink and of many other > processes, including the docker process. Yep, that looks like the network namespace file to me, although I'm not immediately sure why it is unlabeled.
(In reply to Daniel Walsh from comment #4) > ps -eZ | grep unlabeled_t Nothing uncovered.
We have more and more bugs like this where we see unlabeled_t related to docker.
Is this a kernel issue?
It looks like it may be a kernel issue, I'll go ahead and reassign this BZ to take a closer look.
Yes it seems to be something with namespaces.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
I still see this in F23.
Moving to Rawhide to avoid Fedora MASS BUG UPDATEs.
Just please note that we will want it addressed in 22 as well, once the solution is found.
Once we know the root cause of the problem and have a solution in place we can backport to whatever versions of Fedora are currently supported.
Hi, See the AVC: avc: denied { read } for pid=12032 comm="iptables" path="net:[4026531957]" dev="nsfs" ino=4026531957 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 => missing context for the nsfs device Same cause as bug https://bugzilla.redhat.com/show_bug.cgi?id=1234757#c7 , same resolution (see nsfs_fix.patch to be applied to the selinux-policy repo: https://bugzilla.redhat.com/attachment.cgi?id=1090403 ). Best regards, Sébastien
Lukas, see Seb's comments in #16 and the other BZ, what do you think?
Paul, I tried to reproduce this issue and I don't see any AVC. I added SELinux support for nsfs_t filesystem few months ago. I suggest to move this BZ to selinux-policy component and close it.
Okay, thanks for the follow-up on this; moving and closing.