Bug 808052 - With SELinux enabled, nscd can't read /etc/nss_ldap.conf
Summary: With SELinux enabled, nscd can't read /etc/nss_ldap.conf
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-29 12:50 UTC by Oded Arbel
Modified: 2012-03-29 19:46 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-29 17:01:25 UTC
Type: ---


Attachments (Terms of Use)

Description Oded Arbel 2012-03-29 12:50:25 UTC
Description of problem:
the nscd service should be able tor ead /etc/nss_ldap (when nss_ldap) is installed and configured, so that classic (non-sssd) LDAP-based authorization can happen.

Version-Release number of selected component (if applicable):
3.10.0-106.fc17

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 17 (with the default SELinux configuration)
2. install nscd and nss_ldap, configured nss_ldap.conf and configure nsswitch.conf to use it.
3. try to access a system resource (for example 'ls -l /home' or 'id an-ldap-user').
  
Actual results:
The system fails to resolve the user id (ls -l shows UIDs, id reports "no such user").

Expected results:
The user information should be presented

Additional info:
The main reason that this is very annoying, is that without looking in /var/log/messages (where SELinux gets pertty chatty), there is no way for the admin to know that there is a permisission problem - it simply looks like the LDAP access fails, and as that is very fragile on its own, the troubleshooting process will take a long long time. It doesn't help that 'getent passwd' works just fine and that leaves the poor admin completely buffled. 

My current workaround is to connect to the system, after it starts, using root and issuing 'echo 0 > /sys/fs/selinux/enforce' which is obviously broken.

Here's what sealert has to say about this problem:
SELinux is preventing /usr/sbin/nscd from read access on the file /etc/nss_ldap.conf.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that nscd should be allowed read access on the nss_ldap.conf 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:
# grep nscd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:nscd_t:s0
Target Context                unconfined_u:object_r:admin_home_t:s0
Target Objects                /etc/nss_ldap.conf [ file ]
Source                        nscd
Source Path                   /usr/sbin/nscd
Port                          <Unknown>
Host                          chen.office.taboola.com
Source RPM Packages           nscd-2.15-28.fc17.x86_64
Target RPM Packages           nss_ldap-265-10.fc17.x86_64
Policy RPM                    selinux-policy-3.10.0-106.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     chen.office.taboola.com
Platform                      Linux chen.office.taboola.com 3.3.0-5.fc17.x86_64
                              #1 SMP Fri Mar 23 20:10:36 UTC 2012 x86_64 x86_64
Alert Count                   51
First Seen                    Wed 28 Mar 2012 11:58:57 AM IST
Last Seen                     Thu 29 Mar 2012 02:39:44 PM IST
Local ID                      100a896b-9c2a-4a32-b11f-62bb38b3a5ab

Raw Audit Messages
type=AVC msg=audit(1333024784.361:118): avc:  denied  { read } for  pid=1173 comm="nscd" name="nss_ldap.conf" dev="sda4" ino=265766 scontext=system_u:system_r:nscd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file


type=AVC msg=audit(1333024784.361:118): avc:  denied  { open } for  pid=1173 comm="nscd" name="nss_ldap.conf" dev="sda4" ino=265766 scontext=system_u:system_r:nscd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file


type=SYSCALL msg=audit(1333024784.361:118): arch=x86_64 syscall=open success=yes exit=EISDIR a0=7f107e62330c a1=0 a2=1b6 a3=238 items=0 ppid=1 pid=1173 auid=4294967295 uid=28 gid=28 euid=28 suid=28 fsuid=28 egid=28 sgid=28 fsgid=28 tty=(none) ses=4294967295 comm=nscd exe=/usr/sbin/nscd subj=system_u:system_r:nscd_t:s0 key=(null)

Hash: nscd,nscd_t,admin_home_t,file,read

audit2allow

#============= nscd_t ==============
allow nscd_t admin_home_t:file { read open };

audit2allow -R

#============= nscd_t ==============
allow nscd_t admin_home_t:file { read open };

Comment 1 Miroslav Grepl 2012-03-29 13:50:58 UTC
You need to fix labeling for /etc/nss_ldap.conf

Did you move nss_ldap.conf for admin home directory?

Comment 2 Oded Arbel 2012-03-29 17:01:25 UTC
Yes, actually I did. 

I ran restorecon /etc/nss_ldap.conf and now it looks fine. My bad, sorry.

Comment 3 Miroslav Grepl 2012-03-29 19:46:21 UTC
No problem.


Note You need to log in before you can comment on or make changes to this bug.