Bug 244345 - missing filename in setroubleshoot (AVC.get_path() returns incomplete path)
Summary: missing filename in setroubleshoot (AVC.get_path() returns incomplete path)
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setroubleshoot   
(Show other bugs)
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: John Dennis
QA Contact:
: 290111 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-15 07:59 UTC by Jan Hutař
Modified: 2008-02-28 21:43 UTC (History)
2 users (show)

Fixed In Version: 2.0.4-3.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-28 21:43:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0061 normal SHIPPED_LIVE Moderate: setroubleshoot security and bug fix update 2008-05-21 14:25:59 UTC

Description Jan Hutař 2007-06-15 07:59:17 UTC
Description of problem:
setroubleshoot GUI don't show full path to the target file.

I have this AVC in /var/log/audit/audit.log:

type=AVC msg=audit(1180679176.435:2050): avc:  denied  { read } for  pid=18947 
comm="master" name="services" dev=hda2 ino=7881666 
tcontext=user_u:object_r:rpm_script_tmp_t:s0 tclass=file

And using find, I can find the problematic file (but it takes *a while*):

# find / -inum 7881666

But using "sealert -l ..." I got:

    SELinux is preventing the /usr/libexec/postfix/master from using potentially
    mislabeled files (services).

Detailed Description
    SELinux has denied /usr/libexec/postfix/master access to potentially
    mislabeled file(s) (services).  This means that SELinux will not allow
    /usr/libexec/postfix/master to use these files.  It is common for users to
    edit files in their home directory or tmp directories and then move (mv)
    them to system directories.  The problem is that the files end up with the
    wrong file context which confined applications are not allowed to access.

Allowing Access
    If you want /usr/libexec/postfix/master to access this files, you need to
    relabel them using restorecon -v services.  You might want to relabel the
    entire directory using restorecon -R -v .

Additional Information

Source Context                user_u:system_r:postfix_master_t
Target Context                user_u:object_r:rpm_script_tmp_t
Target Objects                services [ file ]
Affected RPM Packages         postfix-2.3.3-2 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.home_tmp_bad_labels
Host Name                     pok
Platform                      Linux pok 2.6.18-8.1.3.el5 #1 SMP Mon Apr 16
                              15:54:12 EDT 2007 i686 i686
Alert Count                   10
Line Numbers

Raw Audit Messages

avc: denied { read } for comm="master" dev=hda2 egid=0 euid=0
exe="/usr/libexec/postfix/master" exit=-13 fsgid=0 fsuid=0 gid=0 items=0
name="services" pid=18947 scontext=user_u:system_r:postfix_master_t:s0 sgid=0
subj=user_u:system_r:postfix_master_t:s0 suid=0 tclass=file
tcontext=user_u:object_r:rpm_script_tmp_t:s0 tty=(none) uid=0

So it advised me to "restorecon -v services" instead of something like 
"restorecon -v /etc/services" which actually solved the issue. I'm not sure if 
this is a bug.

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

How reproducible:

Steps to Reproduce:
1. use the log message above and examine it with setroubleshoot GUI

Actual results:
restorecon -v services

Expected results:
restorecon -v /etc/services

Comment 1 John Dennis 2007-06-26 19:18:24 UTC
The incomplete path information arose from incomplete audit information. In
AVC.get_path() we search for in priority order "file","path","name" in the audit
information. The first entry which is defined is returned as the path
information. It was coded this way because the full path information is not
always available and the thinking was some information is better than none. As
can be seen in the raw AVC only "name" is defined, which is actually the base name.

When setroubleshoot generates a report it utilizes the information returned by
AVC.get_path() without consideration as to whether it is a complete path.

Although the original intent of providing the best available path information
was well intentioned it is clear that because other parts of the system do not
know the path information was a compromise it can generate misleading information.

Yes, I would consider this a bug (although well intentioned :-)

Comment 2 Jan Hutař 2007-06-28 11:26:49 UTC
This is probably same or related issue:

    SELinux is preventing /usr/sbin/httpd (httpd_t) "sys_nice" access to
    <Unknown> (httpd_t).

Detailed Description
    SELinux denied access requested by /usr/sbin/httpd. It is not expected that
    this access is required by /usr/sbin/httpd 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.
    Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for <Unknown>, restorecon -v
    <Unknown>. 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 entirely for the application. Disabling SELinux
    protection is not recommended. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
    Changing the "httpd_disable_trans" boolean to true will disable SELinux
    protection this application: "setsebool -P httpd_disable_trans=1."

    The following command will allow this access:
    setsebool -P httpd_disable_trans=1

Additional Information

Source Context                root:system_r:httpd_t
Target Context                root:system_r:httpd_t
Target Objects                None [ capability ]
Affected RPM Packages         httpd-2.2.3-7.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.disable_trans
Host Name                     ppcp-5server.lab.boston.redhat.com
Platform                      Linux ppcp-5server.lab.boston.redhat.com
                              2.6.18-8.1.6.el5 #1 SMP Fri Jun 1 18:56:29 EDT
                              2007 ppc64 ppc64
Alert Count                   155
Line Numbers

Raw Audit Messages

avc: denied { sys_nice } for comm="httpd" egid=0 euid=0 exe="/usr/sbin/httpd"
exit=0 fsgid=0 fsuid=0 gid=0 items=0 pid=27159 scontext=root:system_r:httpd_t:s0
sgid=0 subj=root:system_r:httpd_t:s0 suid=0 tclass=capability
tcontext=root:system_r:httpd_t:s0 tty=(none) uid=0

# rpm -q setroubleshoot

Comment 3 Jan Hutař 2007-09-03 14:45:04 UTC
Could AVC_PATH messages help to this? It could e.g. in this case (taken from 
bug 252978):

type=AVC msg=audit(1187269176.181:80): avc:  denied  { getattr } for  pid=1909
comm="kadmind" name="kadmin_0" dev=xvda1 ino=228765
scontext=root:system_r:kadmind_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1187269176.181:80): arch=40000003 syscall=195 success=no
exit=-13 a0=803e7b90 a1=bf95f158 a2=6f2ff4 a3=803e7b90 items=0 ppid=1908
pid=1909 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="kadmind" exe="/usr/kerberos/sbin/kadmind"
subj=root:system_r:kadmind_t:s0 key=(null)
type=AVC_PATH msg=audit(1187269176.181:80):  path="/var/tmp/kadmin_0"

Comment 4 John Dennis 2007-09-04 14:35:10 UTC
re comment #3, if the AVC_PATH audit record is available it will be used, this
has always been the case.

Comment 5 John Dennis 2007-09-15 18:29:50 UTC
*** Bug 290111 has been marked as a duplicate of this bug. ***

Comment 6 RHEL Product and Program Management 2007-12-18 22:15:46 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 8 John Dennis 2008-01-09 16:06:12 UTC
The code which handles path information has been completely rewritten in the new
2.0 setroubleshoot release, in addition the audit data which provides the
information has been reworked. We no longer make any assumptions concerning path
information, it's either present in the audit data or it isn't. If it isn't
present the path information will be presented as "<Unknown>".

Comment 10 Fedora Update System 2008-01-15 22:54:47 UTC
setroubleshoot-2.0.2-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setroubleshoot'

Comment 11 Fedora Update System 2008-02-26 02:19:09 UTC
setroubleshoot-plugins-2.0.4-3.fc8,setroubleshoot-2.0.5-2.fc8 has been submitted as an update for Fedora 8

Comment 12 Fedora Update System 2008-02-28 21:43:20 UTC
setroubleshoot-plugins-2.0.4-3.fc8, setroubleshoot-2.0.5-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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