Bug 221060

where i used intro.php since i have no index.html there.

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.

# 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.

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

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 

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)

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.

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.

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.

closing, this bug is pretty old, setroublehshoot has evolved considerably and
this may have been due to installation issues.