Bug 426823 - SELinux generates blizzards of messages after upgrade ....
SELinux generates blizzards of messages after upgrade ....
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2007-12-26 18:14 EST by William A. Mahaffey III
Modified: 2007-12-26 20:24 EST (History)
0 users

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-26 20:24:36 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 William A. Mahaffey III 2007-12-26 18:14:32 EST
Description of problem:
SELinux now (after recent upgrade) generates blizzards of syslog messages about
seemingly innocuous operations. operates usually complete OK, but it washes out
other (possibly important) messages in the syslog file.

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

How reproducible: a bit difficult, I suppose you would need my actual setup. I
upgraded a bunch of stuff (manually) a few days ago & started noticing torrents
of messages from SELinux soon afterward.

Steps to Reproduce:
Actual results:

Expected results:

Additional info: Here is the SYSLOG entry for 1 message:

Dec 26 17:16:59 Q6600 setroubleshoot:      SELinux is preventing
/usr/sbin/rpc.mountd (nfsd_t) "getattr" to /dev/sdc1 (fixed_disk_device_t).    
 For complete SELinux messages. run sealert -l 6464b3f6-26e5-46b7-85c2-5ae9be05738c

& here is the sealert output:

[root@Q6600:/etc, Wed Dec 26, 05:17 PM] 1113 # sealert -l
    SELinux is preventing /usr/sbin/rpc.mountd (nfsd_t) "getattr" to /dev/sdc1

Detailed Description
    SELinux denied access requested by /usr/sbin/rpc.mountd. It is not expected
    that this access is required by /usr/sbin/rpc.mountd 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

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for /dev/sdc1, restorecon -v
    /dev/sdc1 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:nfsd_t
Target Context                system_u:object_r:fixed_disk_device_t
Target Objects                /dev/sdc1 [ blk_file ]
Affected RPM Packages         nfs-utils-1.1.0-4.fc7 [application]
Policy RPM                    selinux-policy-2.6.4-8.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     Q6600
Platform                      Linux Q6600 #1 SMP Thu Sep 27
                              20:47:39 EDT 2007 x86_64 x86_64
Alert Count                   79
First Seen                    Sat Dec 22 21:00:29 2007
Last Seen                     Wed Dec 26 17:16:55 2007
Local ID                      6464b3f6-26e5-46b7-85c2-5ae9be05738c
Line Numbers                  

Raw Audit Messages

avc: denied { getattr } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/rpc.mountd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="sdc1"
path="/dev/sdc1" pid=2815 scontext=system_u:system_r:nfsd_t:s0 sgid=0
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

This only started happening after last update about 4 days ago, everything was
quiet (& enforcing) before that ....
Comment 1 Daniel Walsh 2007-12-26 20:24:36 EST
Please update to the latest version of selinux.

yum update selinux-policy

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