Bug 221060 - setroubleshoot is not reporting avc denials
setroubleshoot is not reporting avc denials
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
6
i686 Linux
medium Severity low
: ---
: ---
Assigned To: John Dennis
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-31 13:48 EST by cornel panceac
Modified: 2008-01-09 12:51 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 12:51:58 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 cornel panceac 2006-12-31 13:48:39 EST
Description of problem:
following these instructions

http://danwalsh.livejournal.com/7995.html

i get 

Dec 31 20:47:23 localhostlocaldomain kernel: audit(1167590843.181:161): 
path="/var/www/html/intro.php"
Dec 31 20:47:23 localhostlocaldomain kernel: audit(1167590843.181:162): avc: 
denied  { getattr } for  pid=2901 comm="httpd" name="intro.php" dev=hdb6
ino=2458812 scontext=user_u:system_r:httpd_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=file
Dec 31 20:47:23 localhostlocaldomain kernel: audit(1167590843.181:162):
arch=40000003 syscall=196 success=no exit=-13 a0=85dbc90 a1=bf812c2c a2=881ff4
a3=2008171 items=0 ppid=2897 pid=2901 auid=500 uid=48 gid=48 euid=48 suid=48
fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd"
subj=user_u:system_r:httpd_t:s0 key=(null)
Dec 31 20:47:23 localhostlocaldomain kernel: audit(1167590843.181:162): 
path="/var/www/html/intro.php"

in var/log/messages

but setroubleshoot is not reporting anything


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 cornel panceac 2006-12-31 13:50:15 EST
where i used intro.php since i have no index.html there.
Comment 2 John Dennis 2006-12-31 14:20:31 EST
setroubleshoot is composed of two parts, a system daemon, setroulbleshootd, and
and a gui desktop component, sealert. Both must be running. setroubleshootd is s
service an is started just like all other services. As root use the 'service'
command to verify if its running, "service setroubleshoot statue", if its not
then do "service setroubleshoot start", to make it runs after booting again use
'chkconfig setroubleshoot on'

sealert is started when you login to your desktop session. Please assure both
have been started by using 'ps ax | egrep setroubleshoot|sealert'. If you didn't
log out and log back in after installing the rpm sealert will not have been
started automatically for you by the session manager, if you go to the menu
'System->Administration->Setroubleshoot' and launch it the alert browser will
come up and it will have been started for you. Closing the browser window will
leave sealert running in the background as if the session manager had started it
for you.

If the problem can be attributed to "first use start up" then please close this
bugzilla.
Comment 3 cornel panceac 2006-12-31 15:13:38 EST
# ps ax | egrep setroubleshoot
 2022 ?        Ssl    0:00 /usr/bin/python -E /usr/sbin/setroubleshootd
 5836 pts/5    R+     0:00 egrep setroubleshoot

# ps ax | egrep sealert
 2728 ?        S      0:00 /usr/bin/python -E /usr/bin/sealert -s
 5829 ?        S      0:00 /usr/bin/python -E /usr/bin/sealert -s
 5840 pts/5    R+     0:00 egrep sealert

opening sealert from menu was of no help, no message appears there while the avc
denial occurs.


Comment 4 cornel panceac 2006-12-31 15:27:10 EST
something strange:

in setroubleshoot browser:

"view audit"

says:
audit listener | loading data done

but shows nothing

and 
"view logfile"

says
unsepcified logfile | loading data done

and of course shows nothing

could be a config file wrong/missing somewhere?

setroubleshoot was removed and reinstalled just before i reported this bug (?)
hence 'rpm -V setroubleshoot' has no output
Comment 5 cornel panceac 2007-01-01 02:10:03 EST
then:

opening sealert -b as root, i select /var/log/audit/audit.log
(as user i have no access to this file)

and i get:

Summary
    SELinux is preventing auditd (auditd_t) "search" access to bin (bin_t).

Detailed Description
    SELinux denied access requested by auditd. It is not expected that this
    access is required by auditd 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 package.

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for bin, restorecon -v bin. 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 "auditd_disable_trans" boolean to true will disable
    SELinux protection this application: "setsebool -P auditd_disable_trans=1."

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

Additional Information:       

Source Context:               system_u:system_r:auditd_t
Target Context:               system_u:object_r:bin_t
Target Objects:               bin [ dir ]
Affected RPM Packages:        
Policy RPM:                   
Selinux Enabled:              
Policy Type:                  
MLS Enabled:                  
Enforcing Mode:               
Plugin Name:                  plugins.disable_trans
Host Name:                    
Platform:                     
Alert Count:                  82
Line Numbers:                 8

Raw Audit Messages:           

avc: denied { search } for comm="auditd" dev=hdb6 name="bin" pid=1963
scontext=system_u:system_r:auditd_t:s0 tclass=dir
tcontext=system_u:object_r:bin_t:s0 

Comment 6 cornel panceac 2007-01-01 02:25:49 EST
oh, and in the mean time, opening /var/log/{messages,dmesg} gives nothing and
rkhunter reports bad md5 hashes on:

/bin/{cat,chmod,chown,date,dmesg,env,grep,kill,login,ls,more,mount,su}
/sbin/ip 
and
/usrbin/{had,du,chattr,md5sum,sha1sum,lsattr,stat,users,wc,wget,whereis,who,whoami}
(if it's relevant, ofcourse, i've run rkhunter --update , previously)
Comment 7 John Dennis 2007-01-02 11:34:53 EST
it would appear your /bin/auditd is mislabled, I'm not sure how that happened,
on my FC6 box I've got this:

$ ls -lZ /sbin/auditd
-rwxr-x---  root root system_u:object_r:auditd_exec_t  /sbin/auditd*

your type is audit_t not auditd_exec_t.

You should be able to fix this by:

restorecon -v /sbin

however if you've got mislabled files in /sbin who knows what else might be
mislabeled, a larger hammer, but one which should get everything is:

touch /.autorelabel; reboot

I don't know what rkhunter is doing but I wonder if it might be responsible for
the mislabeling (only speculation).

let me know if this solves your problems.
Comment 8 cornel panceac 2007-01-02 13:40:57 EST
ok
restorecon -v /sbin was of no use
autorelabel was of no use also (except that the system feels faster now!)

(what i mean is: the sealert doesn't popup on avc denials)

rkhunter afaik only checks, not change anything, and still reports that binaries
broken so, my next step will be to go offline and install coreutils util-linux
e2fsprogs wget iproute and grep with downloaded versions from one known safe mirror.
Comment 9 cornel panceac 2007-01-02 15:25:08 EST
some good news and some bad ones.
i tried installing rkhunter on my other fc6 system i have at home.
i've found out that:
there was nowhere in the repos. i checked the on i have on the broken system. i
discovered was .fc5 (a legacy from the old fc5 wich became fc6 by upgrade)
i installed on the other (clean) system, rkhunter .fc5
i run it and discovered that all binaries were marked as bad.

i checked the binaries with yum info and rpm -qi
the info they provided did not help me to understand if they are the fc6 or the
fc5 version but:

my assumption at this point is that they are the old fc5 version. for
completness i'll put here the list of so called "good" binaries wich i suppose
are actually old fc5 versions.

/bin/netstat                                               [ OK ]
/bin/ps                                                    [ OK ]
  
/sbin/chkconfig                                            [ OK ]
/sbin/depmod                                               [ OK ]
/sbin/ifconfig                                             [ OK ]
/sbin/init                                                 [ OK ]
/sbin/insmod                                               [ OK ]
  
/sbin/lsmod                                                [ OK ]
/sbin/modinfo                                              [ OK ]
/sbin/modprobe                                             [ OK ]
/sbin/rmmod                                                [ OK ]
/sbin/runlevel                                             [ OK ]
/sbin/sulogin                                              [ OK ]
/sbin/sysctl                                               [ OK ]
/sbin/syslogd                                              [ OK ]
   
/usr/bin/file                                              [ OK ]
/usr/bin/find                                              [ OK ]
   
/usr/bin/killall                                           [ OK ]
   
/usr/bin/passwd                                            [ OK ]
/usr/bin/pstree                                            [ OK ]
   
/usr/bin/strings                                           [ OK ]
/usr/bin/top                                               [ OK ]
   
/usr/bin/vmstat                                            [ OK ]
/usr/bin/w                                                 [ OK ]
/usr/bin/watch                                             [ OK ]

now, more and more, the problem looks like an error of upgrading form fc5 to fc6.
so the quick and easy way to fix it may be to actually remove fc6 and reinstall
a clean one.
Comment 10 John Dennis 2008-01-09 12:51:58 EST
closing, this bug is pretty old, setroublehshoot has evolved considerably and
this may have been due to installation issues.

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