Description of problem: I got a SELinux alert on my just installed FC7 Test1 system Version-Release number of selected component (if applicable): shadow-utils-4.0.18.1-9.fc7 How reproducible: Dont know, the alert just popped up Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Here is the alert from the setroubleshoot browser Summary SELinux is preventing /usr/sbin/useradd (useradd_t) "read write" to faillog (var_log_t). Detailed Description SELinux denied access requested by /usr/sbin/useradd. It is not expected that this access is required by /usr/sbin/useradd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for faillog, restorecon -v faillog If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:useradd_t Target Context system_u:object_r:var_log_t Target Objects faillog [ file ] Affected RPM Packages shadow-utils-4.0.18.1-9.fc7 [application] Policy RPM selinux-policy-2.5.2-2.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name localhost Platform Linux localhost 2.6.19-1.2914.fc7 #1 SMP Fri Jan 26 18:42:25 EST 2007 i686 athlon Alert Count 1 Line Numbers Raw Audit Messages avc: denied { read, write } for comm="useradd" dev=sda3 egid=0 euid=0 exe="/usr/sbin/useradd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="faillog" pid=4076 scontext=system_u:system_r:useradd_t:s0 sgid=0 subj=system_u:system_r:useradd_t:s0 suid=0 tclass=file tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=0
Daniel, could you look at this. I was able to reproduce it on rawhide, too.
The problem here is that /var/log/faillog is labeled incorrectly. Some process is recreating this file with the wrong context. restorecon /var/log/faillog will fix the files context and everything should work. Most likely a program removes the file and then recreates the file which would adopt the context of the parent directory var_log_t instead of the defined context faillog_t.
Tim, does restorecon help you?
I have run the 'restorecon /var/log/faillog' command, but i only got the alert once, i don't know what action triggered the alert.
This turned out to be an anaconda problem installation problem. pam was being installed before selinux-policy so files created in the post install were being labeled incorrectly. It is fixed in the next anaconda.