Bug 226951 - SELinux is preventing /usr/sbin/useradd "read write" to faillog
SELinux is preventing /usr/sbin/useradd "read write" to faillog
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2007-02-02 03:27 EST by Tim Lauridsen
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-14 17:04:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Lauridsen 2007-02-02 03:27:50 EST
Description of problem:

I got a SELinux alert on my just installed FC7 Test1 system

Version-Release number of selected component (if applicable):


How reproducible:

Dont know, the alert just popped up

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Here is the alert from the setroubleshoot browser

    SELinux is preventing /usr/sbin/useradd (useradd_t) "read write" to faillog

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- [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
Comment 1 Peter Vrabec 2007-02-05 08:34:28 EST
Daniel, could you look at this. I was able to reproduce it on rawhide, too.

Comment 2 Daniel Walsh 2007-02-05 15:15:31 EST
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.
Comment 3 Peter Vrabec 2007-02-07 10:09:55 EST
Tim, does restorecon help you?
Comment 4 Tim Lauridsen 2007-02-07 10:36:14 EST
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.
Comment 5 Daniel Walsh 2007-02-14 17:04:45 EST
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.

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