Bug 250475 - nfs-utils update spooks selinux
nfs-utils update spooks selinux
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-01 15:58 EDT by Michal Jaegermann
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-24 16:11:34 EDT
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 Michal Jaegermann 2007-08-01 15:58:16 EDT
Description of problem:

After an update to nfs-utils-1.1.0-1.fc7 on a system with
selinux "enforcing" for every 'service nfslock restart' the
following shows up in logs:

SELinux is preventing /usr/sbin/sm-notify (rpcd_t) "search" to <Unknown>

and so on ....  'sealert' produces:

avc: denied { search } for comm="rpc.statd" egid=0 euid=0 exe="/sbin/rpc.statd"
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=3024
scontext=root:system_r:rpcd_t:s0sgid=0 subj=root:system_r:rpcd_t:s0 suid=0
tcontext=system_u:object_r:sysctl_fs_t:s0 tty=(none) uid=0

'rpc.statd' is running after that but what it does is anybodys guess.

I do not have log entries of that sort predating an update but maybe
nfslock was not ever restarted?

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

How reproducible:
on every restart of nfslock
Comment 1 big_green_jelly_bean 2007-08-02 03:03:38 EDT
    SELinux is preventing /usr/sbin/brctl (brctl_t) "getattr" to
    /sys/class/net/virbr0/bridge/forward_delay (sysfs_t).

Detailed Description
    SELinux denied access requested by /usr/sbin/brctl. It is not expected that
    this access is required by /usr/sbin/brctl 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
    /sys/class/net/virbr0/bridge/forward_delay, restorecon -v
    /sys/class/net/virbr0/bridge/forward_delay 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:brctl_t
Target Context                system_u:object_r:sysfs_t
Target Objects                /sys/class/net/virbr0/bridge/forward_delay [ file
Affected RPM Packages         bridge-utils-1.1-2 [application]
Policy RPM                    selinux-policy-2.6.4-29.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   plugins.catchall_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain #1 SMP
                              Fri Jul 27 18:10:34 EDT 2007 i686 i686
Alert Count                   5
First Seen                    Thu 02 Aug 2007 05:02:16 AM EDT
Last Seen                     Thu 02 Aug 2007 02:45:14 AM EDT
Local ID                      3b1de783-ff21-4a20-b225-99bf65f93a6e
Line Numbers                  

Raw Audit Messages            

avc: denied { getattr } for comm="brctl" dev=sysfs egid=0 euid=0
exe="/usr/sbin/brctl" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="forward_delay"
path="/sys/class/net/virbr0/bridge/forward_delay" pid=2558
scontext=system_u:system_r:brctl_t:s0 sgid=0 subj=system_u:system_r:brctl_t:s0
suid=0 tclass=file tcontext=system_u:object_r:sysfs_t:s0 tty=(none) uid=0

Comment 2 big_green_jelly_bean 2007-08-02 03:05:17 EDT
SummarySELinux is preventing access to files with the default label,
default_t.Detailed DescriptionSELinux permission checks on files labeled
default_t are being denied. These files/directories have the default label on
them. This can indicate a labeling problem, especially if the files being
referred to are not top level directories. Any files/directories under standard
system directories, /usr, /var. /dev, /tmp, ..., should not be labeled with the
default label. The default label is for files/directories which do not have a
label on a parent directory. So if you create a new directory in / you might
legitimately get this label.Allowing AccessIf you want a confined domain to use
these files you will probably need to relabel the file/directory with chcon. In
some cases it is just easier to relabel the system, to relabel execute: "touch
/.autorelabel; reboot"Additional InformationSource
Context:  system_u:system_r:procmail_tTarget
Context:  system_u:object_r:default_tTarget Objects:  root [ dir ]Affected RPM
Packages:  procmail-3.22-19.fc7 [application]filesystem-2.4.6-1.fc7
[target]Policy RPM:  selinux-policy-2.6.4-8.fc7Selinux Enabled:  TruePolicy
Type:  targetedMLS Enabled:  TrueEnforcing Mode:  PermissivePlugin
Name:  plugins.defaultHost Name:  localhost.localdomainPlatform:  Linux
localhost.localdomain 2.6.20-2925.9.fc7xen #1 SMP Tue May 22 08:53:03 EDT 2007
i686 i686Alert Count:  2First Seen:  Thu 02 Aug 2007 04:10:29 AM EDTLast
Seen:  Thu 02 Aug 2007 04:34:17 AM EDTLocal
ID:  0a7b47c2-23cd-4159-902a-7aa9cbe0698dLine Numbers:  Raw Audit Messages :avc:
denied { search } for comm="procmail" dev=dm-0 egid=0 euid=0
exe="/usr/bin/procmail" exit=-2 fsgid=0 fsuid=0 gid=0 items=0 name="root"
pid=5990 scontext=system_u:system_r:procmail_t:s0 sgid=0
subj=system_u:system_r:procmail_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:default_t:s0 tty=(none) uid=0 
Comment 3 Steve Dickson 2007-09-14 15:26:28 EDT

Any ideas?
Comment 4 Daniel Walsh 2007-09-18 08:30:03 EDT
The first bug is fixed in the latest selinux-policy.


restorecon -R -v /root 

should fix the other.
Comment 5 Michal Jaegermann 2007-09-24 12:19:32 EDT
> The first bug is fixed in the latest selinux-policy.
It looks like that it worksforme.

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