Bug 826028
| Summary: | SELinux denies socket access to nslcd | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dennis Schridde <devurandom> | |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> | |
| Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 16 | CC: | dwalsh, jhrozek, mgrepl, nalin | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 833387 (view as bug list) | Environment: | ||
| Last Closed: | 2012-06-28 03:27:15 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 833387 | |||
P.S: We setup auth like this: authconfig --enableldap --enableldapauth --disableldaptls --enablemkhomedir --ldapserver=... --ldapbasedn=... --disablesssd --disablekrb5 --updateall P.P.S: Might also have been: authconfig --enableforcelegacy --enableldap --enableldapauth --disableldaptls --enablemkhomedir --ldapserver=... --ldapbasedn=... --updateall But I think that should be equivalent? This doesn't look like nss-pam-ldapd problem to me. I agree that the booleans description looks suspicious. Turning on authlogin_nsswitch_use_ldap means you are using ldap for passwd resolution without using sssd. (In reply to comment #4) > Turning on authlogin_nsswitch_use_ldap means you are using ldap for passwd > resolution without using sssd. In that case the description "Allow users to login using a sssd server" is wrong. That still leaves the connectto and write denials for the nslcd socket. Changed to " Allow users to resolve user passwd entries directly from ldap rather then using a sssd server" Why is abrt trying to connect to the nslcd? Should every domain that needs to connect to ldap be allowed to connect to nslcd? Nevermind it already is. Miroslav, we need to back port F17 abrt.te to F16. Fixed in selinux-policy-3.10.0-89.fc16 selinux-policy-3.10.0-89.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-89.fc16 Package selinux-policy-3.10.0-89.fc16: * should fix your issue, * was pushed to the Fedora 16 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.10.0-89.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9507/selinux-policy-3.10.0-89.fc16 then log in and leave karma (feedback). selinux-policy-3.10.0-89.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: # ausearch -m avc -ts today | grep nslcd type=SYSCALL msg=audit(1338277164.315:55): arch=c000003e syscall=42 success=no exit=-115 a0=b a1=7fc15800a200 a2=10 a3=7fc16f7c0b3c items=0 ppid=1 pid=1042 auid=4294967295 uid=65 gid=55 euid=65 suid=65 fsuid=65 egid=55 sgid=55 fsgid=55 tty=(none) ses=4294967295 comm="nslcd" exe="/usr/sbin/nslcd" subj=system_u:system_r:nslcd_t:s0 key=(null) type=AVC msg=audit(1338277164.315:55): avc: denied { name_connect } for pid=1042 comm="nslcd" dest=389 scontext=system_u:system_r:nslcd_t:s0 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket type=AVC msg=audit(1338286993.506:96): avc: denied { connectto } for pid=3548 comm="abrt-server" path="/run/nslcd/socket" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:nslcd_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1338286993.506:96): avc: denied { write } for pid=3548 comm="abrt-server" name="socket" dev="tmpfs" ino=14059 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nslcd_var_run_t:s0 tclass=sock_ file Version-Release number of selected component (if applicable): nss-pam-ldapd-0.7.13-7.fc16.x86_64 Additional info: # ausearch -m avc -ts today | grep nslcd | audit2why type=AVC msg=audit(1338277164.315:55): avc: denied { name_connect } for pid=1042 comm="nslcd" dest=389 scontext=system_u:system_r:nslcd_t:s0 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket Was caused by: One of the following booleans was set incorrectly. Description: Allow users to login using a sssd server Allow access by executing: # setsebool -P authlogin_nsswitch_use_ldap 1 Description: Allow system to run with NIS Allow access by executing: # setsebool -P allow_ypbind 1 type=AVC msg=audit(1338286993.506:96): avc: denied { connectto } for pid=3548 comm="abrt-server" path="/run/nslcd/socket" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:nslcd_t:s0 tclass=unix_stream_socket Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. type=AVC msg=audit(1338286993.506:96): avc: denied { write } for pid=3548 comm="abrt-server" name="socket" dev="tmpfs" ino=14059 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nslcd_var_run_t:s0 tclass=sock_file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. Setting authlogin_nsswitch_use_ldap=1 ("Allow users to login using a sssd server") appears wrong, as the system is not using SSSD (FORCELEGACY=yes, USESSSD=no). We certainly do not want to login using NIS, either. I assume that either the documentation is wrong (s/sssd/ldap/) or the case where ldap has to be used without sssd is not handled by the policy.