Bug 373981 - setroubleshoot displays confusing information
setroubleshoot displays confusing information
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
8
i686 Linux
low Severity medium
: ---
: ---
Assigned To: John Dennis
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-09 17:52 EST by Konstantin Svist
Modified: 2008-01-09 15:39 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 15:39:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Konstantin Svist 2007-11-09 17:52:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8

Description of problem:
SETroubleshoot displays some error and attempts to guide me through allowing access - but critical information is missing.
Here's what the "Allowing Access" section looks like:

"""
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for , restorecon -v 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 FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package.
"""


The problem is that this sentence doesn't make sense: "You could try to restore the default system file context for , restorecon -v"
I'm not sure what I should do about this error.


Full copy of the alert follows:

'''
Summary
    SELinux is preventing sh (loadkeys_t) "search" to <Unknown>
    (user_home_dir_t).

Detailed Description
    SELinux denied access requested by sh. It is not expected that this access
    is required by sh 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 <Unknown>, restorecon -v
    <Unknown> 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:loadkeys_t:s0
Target Context                system_u:object_r:user_home_dir_t:s0
Target Objects                None [ dir ]
Affected RPM Packages         
Policy RPM                    selinux-policy-3.0.8-44.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     mireille.svist.lan
Platform                      Linux mireille.svist.lan 2.6.23.1-42.fc8 #1 SMP
                              Tue Oct 30 13:55:12 EDT 2007 i686 i686
Alert Count                   17
First Seen                    Thu 08 Nov 2007 03:50:29 PM PST
Last Seen                     Thu 08 Nov 2007 03:50:30 PM PST
Local ID                      e42484f0-60df-4e1a-9237-3b1711da4679
Line Numbers                  

Raw Audit Messages            

avc: denied { search } for comm=sh dev=sda9 name=root pid=3113
scontext=system_u:system_r:loadkeys_t:s0 tclass=dir
tcontext=system_u:object_r:user_home_dir_t:s0
'''

Version-Release number of selected component (if applicable):
selinux-policy-3.0.8-44.fc8

How reproducible:
Always


Steps to Reproduce:
1. I don't know. It looks like booting up the system is enough to cause this message to appear.

Actual Results:


Expected Results:


Additional info:
Comment 1 Daniel Walsh 2007-11-10 07:34:15 EST
For some reason setroubleshoot did not pick up the /root directory, so the
setroubleshoot is supposed to fall back to "root"  But it does not.   The audit
system is supposed to generate a PATH for this, but did not. 

loadkeys not being able to search user_home_dir_t is fixed in
selinux-policy-3.0.8-47.fc8

This can be ignored,and is dontaudited in the updated policy.
Comment 2 Konstantin Svist 2007-11-10 14:56:38 EST
By the way, the version of setroubleshoot I currently have is 1.10.7
Comment 3 John Dennis 2008-01-09 15:39:36 EST
re comment #1, I'm not sure why you believe setroublehoot should have picked up
/root in this instance. There is no path information so setroubleshoot did the
right thing and reported <Unknown>.

It's also a bit difficult to fully diagnose because the complete audit data is
missing, a problem fixed in the setroublehoot 2.0 series.

Closing as I don't see what can be fixed at this point. If this reoccurs with
the 2.0 setroubleshoot series please open a new bug report.

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