Hide Forgot
+++ This bug was initially created as a clone of Bug #1337856 +++ Description of problem: When SSSD container is used for authentication for example via sshd per http://www.projectatomic.io/blog/2015/12/fedora-atomic-sssd-container/, upgrade to Fedora Atomic 23.122 breaks the functionality. Version-Release number of selected component (if applicable): docker-selinux-1.9.1-9.gitee06d03.fc23.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Have IPA server around, create host record for the Fedora Atomic host with OTP set. 2. Have user bob created in the IPA server. 3. On the Fedora Atomic host, run atomic install fedora/sssd --server ipa.example.test --domain example.test --password teslo 4. Run systemctl start sssd 5. Edit /etc/ssh/sshd_config and set PasswordAuthentication to yes. 6. Run systemctl restart sshd 7. Attempt to run ssh bob.test. Actual results: It fails. Journal will say host.example.test audit[1066]: AVC avc: denied { connectto } for pid=1066 comm="sshd" path="/var/lib/sss/pipes/priv ate/pam" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:spc_t:s0 tclass=unix_stream_socket permissive=0 Expected results: No error, authentication passes. Additional info: With docker-selinux-1.9.1-9.gitee06d03.fc23.x86_64 which is on the 23.122 ostree, sesearch --allow -s sshd_t -t spc_t -p connectto does not find anything. It's a regression against for example ostree 23.53 with -bash-4.3# rpm -q docker-selinux docker-selinux-1.9.1-4.git6ec29ef.fc23.x86_64 -bash-4.3# sesearch --allow -s sshd_t -t spc_t -p connectto Found 1 semantic av rules: allow domain spc_t : unix_stream_socket connectto ; --- Additional comment from Jan Pazdziora on 2016-05-20 05:18:59 EDT --- On non-Atomic Fedora with docker-selinux-1.10.3-16.gita41254f.fc23.x86_64, the allow rule is back as well: [root@machine ~]# rpm -q docker-selinux docker-selinux-1.10.3-16.gita41254f.fc23.x86_64 [root@machine ~]# sesearch --allow -s sshd_t -t spc_t -p connectto Found 1 semantic av rules: allow domain spc_t : unix_stream_socket connectto ; But we need the 1.9 policy fixed as well, unless Fedora Atomic is moving to 1.10 soon. --- Additional comment from Daniel Walsh on 2016-06-03 09:08:38 EDT --- I think we are moving to docker-1.10, --- Additional comment from Fedora Admin XMLRPC Client on 2016-06-08 10:09:43 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from Fedora End Of Life on 2016-11-25 04:06:00 EST --- This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Tibor Dudlák on 2016-12-08 07:41:17 EST --- Bug is still present on: fedora-atomic:fedora-atomic/25/x86_64/docker-host Version: 25.42 (2016-11-16 10:26:30) with: docker-1.12.2-5.git8f1975c.fc25.x86_64 container-selinux-1.12.2-5.git8f1975c.fc25.x86_64 selinux-policy-3.13.1-224.fc25.noarch seeing: type=AVC msg=audit(1481200305.628:261): avc: denied { connectto } for pid=3936 comm="sshd" path="/var/lib/sss/pipes/private/pam" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=0 type=AVC msg=audit(1481200305.629:262): avc: denied { connectto } for pid=3936 comm="sshd" path="/var/lib/sss/pipes/private/pam" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=0 --- Additional comment from Daniel Walsh on 2016-12-08 08:08:04 EST --- This looks like the container is running as container_runtime_t not spc_t. Are you running sssd in a confined container? --- Additional comment from Tibor Dudlák on 2016-12-08 09:28:44 EST --- In our case atomic runs: docker run --rm=true --privileged --net=host -v /:/host -e NAME=${NAME} -e IMAGE=${IMAGE} -e HOST=/host ${IMAGE} /bin/install.sh so I have run: docker run --privileged --rm -ti fedora:25 bash and I see process: system_u:system_r:container_runtime_t:s0 root 4560 0.0 0.1 12556 3660 pts/1 Ss+ 13:56 0:00 bash when run without --privileged the type is: system_u:system_r:container_t:s0:c844,c851 root 4922 0.2 0.1 12560 3656 pts/1 Ss+ 14:26 0:00 bash Did not spc_t get renamed to container_runtime_t lately? --- Additional comment from Tibor Dudlák on 2016-12-08 09:37:10 EST --- BTW we have same regression on RHEL 7.3.1 with: rhel-atomic-host:rhel-atomic-host/7/x86_64/standard Version: 7.3.1 (2016-11-30 02:14:24) docker-1.10.3-59.el7.x86_64 container-selinux-1.10.3-59.el7.x86_64 selinux-policy-3.13.1-102.el7_3.7.noarch seeing: Dec 08 14:31:19 test1-rhel-7-3-1-atomic.example.test kernel: type=1400 audit(1481207479.847:5): avc: denied { connectto } for pid=13179 comm="sshd" path="/var/lib/sss/pipes/private/pam" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket Dec 08 14:31:19 test1-rhel-7-3-1-atomic.example.test kernel: type=1400 audit(1481207479.867:6): avc: denied { connectto } for pid=13179 comm="sshd" path="/var/lib/sss/pipes/private/pam" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket Would you like to track RHEL issue separately?
The problem here is sssd is not running as spc_t? It should not be running as container_runtime_t:s0 Is this actually happening in RHEL or is this just happening in Fedora?
Both. This bugzilla is a clone of the original Fedora report, to track the fix specifically against RHEL.
if you run docker run --privileged fedora cat /proc/self/attr/cuttent What do you see?
On Rawhide I am seeing docker run --rm --privileged fedora cat /proc/self/attr/current system_u:system_r:spc_t:s0
-bash-4.2# rpm-ostree status State: idle Deployments: ● rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard Version: 7.3.1 (2016-11-30 02:14:24) Commit: 42cfe1ca3305defb16dfd59cd0be5c539f19ea720dba861ed11e13941423ae86 OSName: rhel-atomic-host -bash-4.2# docker run --rm --privileged fedora:24 cat /proc/self/attr/current system_u:system_r:container_runtime_t:s0
This means that their is no transition happening, and privileged containers are running as the same label as docker. What back end are you seeing this with? On Rawhide I see these rules. sesearch -T -s container_runtime_t -c process | grep spc_t type_transition container_runtime_t container_var_lib_t : process spc_t; type_transition container_runtime_t container_share_t : process spc_t; type_transition container_runtime_t container_file_t : process spc_t;
Is /var/lib/docker mounted NOSUID?
-bash-4.2# rpm-ostree status State: idle Deployments: ● rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard Version: 7.3.1 (2016-11-30 02:14:24) Commit: 42cfe1ca3305defb16dfd59cd0be5c539f19ea720dba861ed11e13941423ae86 OSName: rhel-atomic-host -bash-4.2# mount -l | grep var /dev/mapper/atomicos-root on /var type xfs (rw,relatime,seclabel,attr2,inode64,noquota) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
restorecon -R -v /var/lib/docker Do anything?
-bash-4.2# restorecon -R -v /var/lib/docker restorecon reset /var/lib/docker/containers/6192c9e5b08be21af3856a4a89be924898803eb42ffd1d4c421f00dc3d11064d/6192c9e5b08be21af3856a4a89be924898803eb42ffd1d4c421f00dc3d11064d-json.log context system_u:object_r:container_var_lib_t:s0->system_u:object_r:container_log_t:s0 -bash-4.2# docker run --rm --privileged fedora:24 cat /proc/self/attr/current system_u:system_r:container_runtime_t:s0
BTW, It works well with AH 7.3. So it's a regression in Atomic Host -bash-4.2# rpm-ostree status State: idle Deployments: ● rhel7-atomic:rhel-atomic-host/7/x86_64/standard Version: 7.3 (2016-10-26 14:24:09) Commit: 90c9735becfff1c55c8586ae0f2c904bc0928f042cd4d016e9e0e2edd16e5e97 OSName: rhel7-atomic -bash-4.2# docker run --rm --privileged fedora cat /proc/self/attr/current system_u:system_r:spc_t:s0-bash-4.2#
There is a missing transition rule for container_runtime_t@unlabeled_t->spc_t. This rule is being removed from Fedora but should have been left in for RHEL. https://github.com/projectatomic/container-selinux/commit/cc14935f9a5ee1977b853dc85b3dd4ba3a16d320 Lokesh we need a new build for RHEL including this change.
Move to verified with container-selinux-1.12.5-9.el7.x86_64 # sesearch --allow -s sshd_t -t spc_t -p connectto Found 1 semantic av rules: allow domain spc_t : unix_stream_socket connectto ; # sesearch -T -s container_runtime_t -c process | grep spc_t type_transition container_runtime_t container_var_lib_t : process spc_t; type_transition container_runtime_t container_share_t : process spc_t; type_transition container_runtime_t unlabeled_t : process spc_t;
(In reply to Luwen Su from comment #25) > Move to verified with container-selinux-1.12.5-9.el7.x86_64 Did you also verify the functionality of authentication itself?
Moving back to ON_QA for full verification of comment 0.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2017-0116.html