Nagios Web Interface and SELinux
by Ryan Skadberg
I have been trying to get nagios up and running on 2 different
machines. One running FC5 and one running FC6. Nagios itself starts
up fine, but the web interface fails miserably.
When looking at /var/log/messages, I see things like:
Dec 3 11:38:17 xray kernel: audit(1165174697.348:289): avc: denied
{ execute_no_trans } for pid=22237 comm="httpd" name="tac.cgi"
dev=dm-0 ino=11272226 scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
I noticed in the selinux-policy-targeted Changelog:
* Wed Jul 26 2006 Dan Walsh <dwalsh(a)redhat.com> 2.3.3-13
- Add nagios policy
This may have been for the program itself or maybe the web interface,
but it sure doesn't seem to be working for me.
Both systems are set to:
SELINUX=enforcing
SELINUXTYPE=targeted
SETLOCALDEFS=0
Anyone have any advice on how to fix this?
Thanks!
Skadz
16 years, 7 months
cups/snmpd_var_lib_t
by Tom London
Got this when printing:
Summary
SELinux is preventing /usr/lib/cups/backend/hp (cupsd_t) "getattr" to
/usr/share/snmp/mibs/.index (snmpd_var_lib_t).
Detailed Description
SELinux denied access requested by /usr/lib/cups/backend/hp. It is not
expected that this access is required by /usr/lib/cups/backend/hp 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 /usr/share/snmp/mibs/.index,
restorecon -v /usr/share/snmp/mibs/.index 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:cupsd_t:SystemLow-SystemHigh
Target Context system_u:object_r:snmpd_var_lib_t
Target Objects /usr/share/snmp/mibs/.index [ file ]
Affected RPM Packages hplip-2.7.7-4.fc8 [application]
Policy RPM selinux-policy-3.0.7-10.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name localhost.localdomain
Platform Linux localhost.localdomain 2.6.23-0.174.rc6.fc8
#1 SMP Tue Sep 11 19:06:17 EDT 2007 i686 i686
Alert Count 4
First Seen Wed 12 Sep 2007 09:09:26 AM PDT
Last Seen Wed 12 Sep 2007 09:11:38 AM PDT
Local ID 147ebf61-d964-48b7-b572-befcad9e1411
Line Numbers
Raw Audit Messages
avc: denied { getattr } for comm=hp dev=dm-0 egid=7 euid=4
exe=/usr/lib/cups/backend/hp exit=-13 fsgid=7 fsuid=4 gid=7 items=0
path=/usr/share/snmp/mibs/.index pid=6246
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 sgid=7
subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 suid=4 tclass=file
tcontext=system_u:object_r:snmpd_var_lib_t:s0 tty=(none) uid=4
--
Tom London
16 years, 7 months
maxima fails to load because of selinux, other things happening
by Antonio Olivares
Dear all,
I am having difficulties with maxima because of selinux. Other denied avcs have been corrected by following troubleshooters advice.
avc: denied { create } for comm="newaliases" egid=51 euid=0 exe="/usr/sbin/sendmail.sendmail" exit=-13 fsgid=51 fsuid=0 gid=0 items=0 name="aliases.db" pid=7643 scontext=system_u:system_r:sendmail_t:s0 sgid=51 subj=system_u:system_r:sendmail_t:s0 suid=0 tclass=file tcontext=system_u:object_r:etc_aliases_t:s0 tty=(none) uid=0
restorecon -v aliases.db
[olivares@localhost ~]$ su -
Password:
[root@localhost ~]# restorecon -v aliases.db
restorecon: stat error on aliases.db: No such file or directory
[root@localhost ~]#
avc: denied { execmem } for comm="mplayer" egid=500 euid=500 exe="/usr/local/bin/mplayer" exit=-13 fsgid=500 fsuid=500 gid=500 items=0 pid=3151 scontext=system_u:system_r:unconfined_t:s0 sgid=500 subj=system_u:system_r:unconfined_t:s0 suid=500 tclass=process tcontext=system_u:system_r:unconfined_t:s0 tty=(none) uid=500
[root@localhost ~]# chcon -t unconfined_execmem_exec_t /usr/local/bin/mplayer
[root@localhost ~]# semanage fcontext -a -t unconfined_execmem_exec_t /usr/local/bin/mplayer
[root@localhost ~]#
[olivares@localhost ~]$ maxima &
[1] 3834
[olivares@localhost ~]$ xmaxima &
[2] 3859
[1] Segmentation fault maxima
[olivares@localhost ~]$ su -
Password:
[root@localhost ~]# chcon -t unconfined_execmem_exec_t /usr/lib/maxima/5.13.0/binary-gcl/maxima
[root@localhost ~]# semanage fcontext -a -t unconfined_execmem_exec_t /usr/lib/maxima/5.13.0/binary-gcl/maxima
[root@localhost ~]# chcon -t unconfined_execmem_exec_t /usr/lib/maxima/5.13.0/binary-gcl/maxima
[root@localhost ~]#
[root@localhost ~]# chcon -t textrel_shlib_t /usr/lib/maxima/5.13.0/binary-gcl/maxima
[root@localhost ~]# semanage fcontext -a -t textrel_shlib_t /usr/lib/maxima/5.13.0/binary-gcl/maxima
[root@localhost ~]#
Did not work so I filed a bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=287761
Regards,
Antonio
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
16 years, 7 months
Error: setroubleshootd dead but subsys locked (Repost)
by Steven Stromer
Had a strange, and as yet unexplained, 'event' (I wasn't in front of the
machine when things went weird) that took place while a system was left
running a large rsync over ssh. On returning, a majority of the
directories under /var vanished, and a number of services refused to
start after a reboot, including auditd, nfsd, system message bus, hpiod,
hpssd, mysql, syslogd, httpd, sm-client, and setroubleshootd.
In the cases of most of these services, there seemed to be problems
either with orphaned /var/run/*.pid files, or with orphaned
/var/lock/subsys/* lock files. Also, many services were reporting
'subsys locked'. Deleting orphaned files, followed by relabeling the
filesystem selinux permissions did the trick, with relabeling being the
key to getting things going again. Debugging was made more challenging
by the fact that I had no logs to refer to.
Now, almost all seems well, but I can't get setroubleshootd to start
unless I select 'setroubleshootd_disable_trans'. Without this checked,
setroubleshootd seems to start, but then fails:
[root@file1 subsys]# rm setroubleshootd
rm: remove regular empty file `setroubleshootd'? y
[root@file1 subsys]# service setroubleshoot status
setroubleshootd is stopped
[root@file1 subsys]# service setroubleshoot start
Starting setroubleshootd: [ OK ]
[root@file1 subsys]# service setroubleshoot status
setroubleshootd dead but subsys locked
Attempting to run setroubleshoot generates the error:
'attempt to open server connection failed: (2, 'No such file or directory')
Since someone might ask about permissions:
[root@file1 subsys]# ls -laRZ /var/log | grep setroubleshoot
drwxr-xr-x root root system_u:object_r:setroubleshoot_var_log_t
setroubleshoot
/var/log/setroubleshoot:
drwxr-xr-x root root system_u:object_r:setroubleshoot_var_log_t .
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log.1
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log.2
Can anyone explain why setroubleshootd_disable_trans should need to be
selected? Also, since this entire event seems to have close ties to
selinux, would anyone have an idea what might have happened to this system?
Thanks for any ideas; it's been a long day...
Steven Stromer
16 years, 7 months
denied avc for wine
by Antonio Olivares
Finally,
the denied avc for wine appeared. Wine started working yesterday and it is running now and here is the avc denial for it.
Summary
SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "unix_read unix_write"
to <Unknown> (wine_t).
Detailed Description
SELinux denied access requested by /usr/bin/Xorg. It is not expected that
this access is required by /usr/bin/Xorg 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
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:xdm_xserver_t:SystemLow-
SystemHigh
Target Context system_u:system_r:wine_t
Target Objects None [ shm ]
Affected RPM Packages xorg-x11-server-Xorg-1.3.0.0-23.fc8 [application]
Policy RPM selinux-policy-3.0.7-10.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall
Host Name localhost
Platform Linux localhost 2.6.23-0.174.rc6.fc8 #1 SMP Tue
Sep 11 19:06:17 EDT 2007 i686 athlon
Alert Count 2
First Seen Wed 12 Sep 2007 08:10:49 AM CDT
Last Seen Wed 12 Sep 2007 08:10:49 AM CDT
Local ID 8b5115b9-d7d8-40de-8f2b-5ffb7e7ecfb7
Line Numbers
Raw Audit Messages
avc: denied { unix_read, unix_write } for comm=X egid=0 euid=0 exe=/usr/bin/Xorg
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=2440
scontext=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023 suid=0 tclass=shm
tcontext=system_u:system_r:wine_t:s0 tty=tty7 uid=0
Please advice on how to deal with this. I was quiet and using another computer but now since wine started working I came back to it and I saw this.
Thanks,
Antonio
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
16 years, 7 months
Error: setroubleshootd dead but subsys locked
by Steven Stromer
Had a strange, and as yet unexplained, 'event' (I wasn't in front of the
machine when things went weird) that took place while a system was left
running a large rsync over ssh. On returning, a majority of the
directories under /var vanished, and a number of services refused to
start after a reboot, including auditd, nfsd, system message bus, hpiod,
hpssd, mysql, syslogd, httpd, sm-client, and setroubleshootd.
In the cases of most of these services, there seemed to be problems
either with orphaned /var/run/*.pid files, or with orphaned
/var/lock/subsys/* lock files. Also, many services were reporting
'subsys locked'. Deleting orphaned files, followed by relabeling the
filesystem selinux permissions did the trick, with relabeling being the
key to getting things going again. Debugging was made more challenging
by the fact that I had no logs to refer to.
Now, almost all seems well, but I can't get setroubleshootd to start
unless I select 'setroubleshootd_disable_trans'. Without this checked,
setroubleshootd seems to start, but then fails:
[root@file1 subsys]# rm setroubleshootd
rm: remove regular empty file `setroubleshootd'? y
[root@file1 subsys]# service setroubleshoot status
setroubleshootd is stopped
[root@file1 subsys]# service setroubleshoot start
Starting setroubleshootd: [ OK ]
[root@file1 subsys]# service setroubleshoot status
setroubleshootd dead but subsys locked
Attempting to run setroubleshoot generates the error:
'attempt to open server connection failed: (2, 'No such file or directory')
Since someone might ask about permissions:
[root@file1 subsys]# ls -laRZ /var/log | grep setroubleshoot
drwxr-xr-x root root system_u:object_r:setroubleshoot_var_log_t
setroubleshoot
/var/log/setroubleshoot:
drwxr-xr-x root root system_u:object_r:setroubleshoot_var_log_t .
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log.1
-rw-r--r-- root root system_u:object_r:setroubleshoot_var_log_t
setroubleshootd.log.2
Can anyone explain why setroubleshootd_disable_trans should need to be
selected? Also, since this entire event seems to have close ties to
selinux, would anyone have an idea what might have happened to this system?
Thanks for any ideas; it's been a long day...
Steven Stromer
16 years, 7 months
Labelling a new port
by Konstantin Ryabitsev
Hello, all:
I'm trying to write a policy for memcached, but I'm not sure how I'd
declare a new memcached_port_t (11211/tcp). Any pointers?
TIA!
Cheers,
--
Konstantin Ryabitsev
Montréal, Québec
16 years, 7 months
anybody running backup and virus scanner solution on SELinux
by bala
Hi All,
We would like to know, anybody using
commercial [OR] open source based backup and
virus scanner products on SELinux environement.
pls share and suggest some products that runs
and tested on SELinux environment.
thanks in advance,
-bala-
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
16 years, 7 months
setroubleshootd: write access to "system_bus_socket" ....?
by Tom London
Running latest rawhide, targeted/enforcing.
Just started noticing this:
type=AVC msg=audit(1189383749.641:16): avc: denied { write } for
pid=3307 comm="setroubleshootd" name="system_bus_socket" dev=dm-0
ino=65933 scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1189383749.641:16): arch=40000003 syscall=102
success=no exit=-13 a0=3 a1=bf980f90 a2=8c5474 a3=0 items=0 ppid=1
pid=3307 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="setroubleshootd" exe="/usr/bin/python"
subj=system_u:system_r:setroubleshootd_t:s0 key=(null)
[tbl@localhost ~]$ ls -lZ /var/run/dbus/system*
srwxrwxrwx root root system_u:object_r:system_dbusd_var_run_t
/var/run/dbus/system_bus_socket
[tbl@localhost ~]$
tom
--
Tom London
16 years, 7 months
order of rules?
by "Stanisław T. Findeisen"
Please tell me if the following is correct about resource access in SELinux:
(1) everything is denied by default
(2) administrator can add "allow" rules
(3) SO, there is nothing about "rule chains", like in iptables. There is
just rule SET. In other words, order of rules is not significant.
True or false?
Thanks.
--
"Serce medrcow jest w domu zaloby,
a serce glupcow w domu wesela." (Koh 7:4)
16 years, 7 months
