Bug 446499

It's definitely a selinux issue, because it dissapear if setting enforcing mode
to permissive. And the cause is probably not on nscd nor nss-ldap.

The .ldapcache file is generated with a cron job (file on /etc/cron.d/), and is
created with a non suitable context :
# ls -alZ /tmp/.ldapcache 
-rw-------  nscd nscd system_u:object_r:system_crond_tmp_t:s0 /tmp/.ldapcache

I don't see where this file is being created -- is its creation a
locally-configured thing?

Sorry, the credential cache is initialized with a cron job:

# ls -alZ /etc/cron.d/nss-ldap
-rw-r--r--  root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/nss-ldap

# cat /etc/cron.d/nss-ldap 
@reboot nscd /usr/kerberos/bin/kinit -c /tmp/.ldapcache -k -t /etc/nss.keytab
nss/carpanta.home.local 
@hourly nscd /usr/kerberos/bin/kinit -c /tmp/.ldapcache -k -t /etc/nss.keytab
nss/carpanta.home.local 

Please attach the avc messages from /var/log/audit/audit.log

If you put the ldapcache in /var/run/nscd would it still work?

The audit messages are the ones on bug 446482. I'll perform a reinstall and
attach them from a fresh system.

As I understand, you mean use /var/run/nscd/.ldapcache instead of
/tmp/.ldapcache. I'll test and come back.

Yes that is the idea.  System jobs like nscd should not rely on data that can be
mucked with by unprivileged users.

Created attachment 305807 [details]
SELinux policy from permissive mode

I've not tested the /var/run/nscd yet, partly because that requires root
permissions for the credentials.

I've performed a first install with selinux in permissive mode. After performing
some task up to the login of a nss-ldap user, I've collected a SElinux policy
with audit2allow. On later installations, I load that policy, running `semodule
-i` on %post.

With this procedure I get a silent system working properly if the enforcing mode
is permissive, but if I switch to enforcing, non local users and groups are not
mapped although no selinux message appears on logs, and everything else is
exactly the same (I use two kickstart files which only differ on selinux entry)

semodule -DB 

Will turn off dontaudit rules.  Something is blocking an AVC in enforcing mode.

Probably a getattr on system_crond_tmp_t file

Attempt to login, additional avc's will be generated.

semodule -B 

Will turn the extra messages off again

I will probably have no time to come back in a couple of days, but a fast test
in permissive mode shows one interesting entry that might have sense for you

allow semanage_t nscd_t:nscd shmemhost;

It might not be related, bu I've also noticed that nscd tends to die with this
setup.

Not likely related,

I've probably found the solution. I will be able to reinstall in a couple of
days, but looks like the rules below work

allow nscd_t system_crond_tmp_t:file read;
allow nscd_t system_crond_tmp_t:file lock;
allow nscd_t system_chkpwd_t:dir search;

I'm not sure wether I've seen the lock one before, and it was the one that made
everything work.

On the way I did also upgraded a bunch of packages, so I'll come back with
(hopefully) the solution on clean and upgraded system.

Finally, I got policies that work, both in fresh and upgraded systems. The
policy for nscd, which is actually required when using SASL-GSSAPI
authentication for the LDAP server is

allow nscd_t system_crond_tmp_t:file { read lock };
allow nscd_t krb5_conf_t:file getattr;
allow nscd_t system_chkpwd_t:dir search;

Althought not strictly related to this tickets, I did also enabled the policy
reported on bug 447096, and the policy below, which is closely related to bug
446482 :

allow local_login_t file_context_t:file { read getattr };
allow local_login_t krb5_conf_t:file write;
allow local_login_t self:process setfscreate;

allow sshd_t krb5_conf_t:file write;

allow xdm_t file_context_t:file { read getattr };
allow xdm_t krb5_conf_t:file { write getattr };
allow xdm_t self:process setfscreate;

I have realized that the updated selinux-policy package version is 3.3.1-55, so
the policy for krb5 mentioned before can be safely removed.

So can you remove all of your modifications, and the policy works?

Please try with policy 62?

Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.