From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.6) Gecko/20050313 Epiphany/1.5.8 Description of problem: Fedora's strict SELinux policy does not allow login programs to perform the operations required to authenticate a user using pam_ccreds. Pam_ccreds allows one to cache login credentials so that a laptop may authenticate a user even when disconnected from its kerberos network. Version-Release number of selected component (if applicable): selinux-policy-strict-1.23.6-3 How reproducible: Always Steps to Reproduce: 1. Tell SELinux to enforce the strict Fedora policy. 2. Configure the system to use pam_ccreds. 3. Try to log in to the system. Actual Results: The login will fail. Expected Results: The user should be able to log in. Additional info: Telling SELinux not to enforce its policy allows the user to log in. The following gets rid of the AVC messages printed when a login fails (but the login still fails): allow local_login_t var_t:file { lock getattr read write }; allow local_login_t var_t:dir write; allow udev_t net_conf_t:file { getattr read }; allow udev_t udev_t:tcp_socket { create connect setopt shutdown }; allow udev_t netif_type:netif { tcp_send }; allow udev_t node_t:node { tcp_send }; allow udev_t ldap_port_t:tcp_socket { send_msg }; However, logging in still fails when SELinux is on and succedes when it is off. I suspect there are some AVC messages that are being suppressed. Also, I am not sure why udev_t is involved.
Could you attach your AVC messages?
Here are some AVC messages resulting from a "su - user" when my Kerberos server is not available and cached credentials must be used: Apr 21 11:36:46 imp kernel: audit(1114101406.432:0): avc: denied { getattr } for pid=6437 exe=/bin/su path=/var/cache/.security.db dev=dm-0 ino=374768 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:var_t tclass=file Apr 21 11:36:46 imp kernel: audit(1114101406.433:0): avc: denied { read } for pid=6437 exe=/bin/su name=.security.db dev=dm-0 ino=374768 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:var_t tclass=file Apr 21 11:36:46 imp kernel: audit(1114101406.695:0): avc: denied { lock } for pid=6437 exe=/bin/su path=/var/cache/.security.db dev=dm-0 ino=374768 scontext=user_u:user_r:user_su_t tcontext=user_u:object_r:var_t tclass=file I've also seen this: Apr 21 11:24:21 imp nscd: 2676 avc: denied { shmempwd } for scontext=user_u:user_r:user_su_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:23 imp nscd: 2676 avc: denied { shmemhost } for scontext=user_u:user_r:user_su_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:46 imp nscd: 2676 avc: denied { shmemgrp } for scontext=user_u:user_r:user_su_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:46 imp nscd: 2676 avc: denied { shmempwd } for scontext=user_u:user_r:user_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:46 imp nscd: 2676 avc: denied { shmempwd } for scontext=user_u:user_r:user_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:46 imp nscd: 2676 avc: denied { shmemgrp } for scontext=user_u:user_r:user_t tcontext=system_u:system_r:nscd_t tclass=nscd Apr 21 11:24:46 imp nscd: 2676 avc: denied { shmempwd } for scontext=user_u:user_r:user_t tcontext=system_u:system_r:nscd_t tclass=nscd I finally got pam_ccreds to work with the strict policy using the following (may not be correct way to do it): allow local_login_t var_t:file { lock getattr read write }; allow local_login_t var_t:dir write; allow udev_t net_conf_t:file { getattr read }; allow udev_t udev_t:tcp_socket { create connect setopt shutdown }; allow udev_t netif_type:netif { tcp_send }; allow udev_t node_t:node { tcp_send }; allow udev_t ldap_port_t:tcp_socket { send_msg }; allow user_su_t nscd_t:nscd { shmemhost shmempwd }; # no shmempwd = segfault! allow user_su_t nscd_t:fd { use }; # no user = segfault! allow sysadm_t nscd_t:nscd { shmempwd shmemgrp }; allow user_t user_su_t:process { siginh rlimitinh noatsecure }; allow user_su_t nscd_var_run_t:dir { search }; allow user_su_t nscd_var_run_t:file { read getattr }; # no shmempwd = segfault! allow user_su_t var_t:file { getattr read write lock }; allow user_su_t var_t:dir { write }; # allow user_su_t shadow_t:file { read }; # assertion fails allow user_su_t ldap_port_t:tcp_socket { name_connect }; allow user_su_t user_chkpwd_t:process { siginh rlimitinh noatsecure }; allow user_chkpwd_t nscd_var_run_t:dir { search }; allow user_t nscd_var_run_t:dir { search }; allow user_t nscd_t:nscd { shmempwd shmemgrp shmempwd };
Have you tried this with the latest policy? Do you have ypbind running on your machine?
I do not have ypbind running. I am using ldap + pam_krb5. I will attach a copy of the AVC messages produced when I log in when SELinux is and isn't enforcing its policy. It looks like the newer versions of the policy (I'm using selinux-policy-strict-1.25.3-3 now) have different symptoms.
Created attachment 117137 [details] Login logs: ENFORCING selinux-policy-strict-1.25.3-3
Created attachment 117138 [details] Login logs: NOT ENFORCING selinux-policy-strict-1.25.3-3
Created attachment 117139 [details] Login logs: DISCONNECTED ENFORCING selinux-policy-strict-1.25.3-3 This log was captured while logging in with the laptop disconnected from the network, forcing pam_ccreds to attempt to authenticate.
setting priority to high since logs are attached
Could you send me you pam files with the ccreds entries? Dan
Bug #145044 documents how to configure pam_ccreds. See the fourth comment.
There is no way this will ever work with SELinux, so you need to turn off SELinux. Hopefull Single Sign on work will end up generating a better solution.