Hi,
I've got httpd running on CentOS-5 with all the latest update.
I'm getting the following AVC denied messages from SElinux. Now I don't want to disable SElinux for the httpd daemon as this server will be available on the internet.
1.
[root@alpha ~]# sealert -l 8c3ce37b-fbf3-459b-87d9-e4c4727276eb
Summary
SELinux is preventing /usr/sbin/httpd (httpd_t) "sys_nice" access to
<Unknown> (httpd_t).
Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try
to restore the default system file context for <Unknown>,
restorecon -v <Unknown>.
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=2241
scontext=system_u:system_r:httpd_t:s0 sgid=0 subj=system_u:system_r:httpd_t:s0
suid=0 tclass=capability tcontext=system_u:system_r:httpd_t:s0 tty=(none) uid=0
2.
[root@alpha ~]# sealert -l 87d837ba-bae0-4cbc-8a93-344e6dc67295
Summary
SELinux is preventing the /bin/netstat from using potentially
mislabeled files net (proc_net_t).
Detailed Description
SELinux has denied the /bin/netstat access to potentially mislabeled
files net. This means that SELinux will not allow http to use these
files. Many third party apps install html files in directories that
SELinux policy can not predict. These directories have to be labeled
with a file context which httpd can accesss.
Allowing Access
If you want to change the file context of net so that the httpd daemon
can access it, you need to execute it using
chcon -t httpd_sys_content_t.net.
You can look at the httpd_selinux man page for additional information.
Raw Audit Messages
avc: denied { read } for comm="netstat" dev=proc egid=0 euid=0
exe="/bin/netstat" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="net" pid=2255 scontext=system_u:system_r:httpd_t:s0 sgid=0 subj=system_u:system_r:httpd_t:s0
suid=0 tclass=dir tcontext=system_u:object_r:proc_net_t:s0 tty=(none) uid=0
3.
[root@alpha ~]# sealert -l b6d8bb36-32f7-4b10-9c09-331c6298fede
Summary
SELinux is preventing /bin/netstat (httpd_t) "create" access to
<Unknown> (httpd_t).
Raw Audit Messages
avc: denied { create } for comm="netstat" egid=0 euid=0 exe="/bin/netstat"
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=2255
scontext=system_u:system_r:httpd_t:s0 sgid=0 subj=system_u:system_r:httpd_t:s0
suid=0 tclass=socket tcontext=system_u:system_r:httpd_t:s0 tty=(none) uid=0
The test server seems to be working OK, so are these messages I can safely ignore. Alternatively how can I get rid of them without disaling SElinux for the httpd server.
Regards,
Tony
--
Tony Molloy.
System Manager.
Dept. of Comp. Sci.
University of Limerick
I recently upgraded policy from selinux-policy-strict-2.4.6-57.fc6 to
selinux-policy-strict-2.4.6-69.fc6.
As a consequence of which I started to see the following errors
in /var/log/cron every 10minutes:
...
May 30 07:40:01 topaz crond[3717]: Authentication service cannot
retrieve authentication info
May 30 07:40:01 topaz crond[3717]: CRON (root) ERROR: failed to open PAM
security session: Success
May 30 07:40:01 topaz crond[3717]: CRON (root) ERROR: cannot set
security context
May 30 07:50:01 topaz crond[3727]: Authentication service cannot
retrieve authentication info
May 30 07:50:01 topaz crond[3727]: CRON (root) ERROR: failed to open PAM
security session: Success
May 30 07:50:01 topaz crond[3727]: CRON (root) ERROR: cannot set
security context
...
Meanwhile, SELinux/syslog errors shows:
May 30 02:40:01 topaz kernel: audit(1180489201.806:13): avc: denied
{ execute } for pid=3860 comm="crond" name="unix_chkpwd" dev=hda2
ino=453913 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:chkpwd_exec_t:s0 tclass=file
May 30 02:40:01 topaz crond[3860]: pam_unix(crond:account): helper
binary execve failed: Permission denied
May 30 02:40:01 topaz crond[3859]: Authentication service cannot
retrieve authentication info
The cron Job which appeared to error was for sysstat, as in:
[root@topaz ~]# cat /etc/cron.d/sysstat
# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib/sa/sa2 -A
[root@topaz ~]#
Looking at the policy changes for cron in policy 69, I see that the
auth_domtrans_chk_passwd(crond_t) transition has been removed, ( see
diff below ).
By adding this entry back into the selinux policy for crond_t, I was
apparently able to restore correct operation of cron:
auth_domtrans_chk_passwd(crond_t)
Is that the correct fix, or does the problem really lie in recoding
crond itself to use unix_update instead of unix_chkpwd ??
===================================================================
...
[root@topaz BUILD]# diff -uNr
serefpolicy-2.4.6-57/policy/modules/services/cron.te
serefpolicy-2.4.6-69/policy/modules/services/cron.te
--- serefpolicy-2.4.6-57/policy/modules/services/cron.te
2007-04-27 08:47:01.000000000 +0100
+++ serefpolicy-2.4.6-69/policy/modules/services/cron.te
2007-05-30 08:57:20.000000000 +0100
@@ -73,7 +73,9 @@
# Cron Local policy
#
-allow crond_t self:capability { dac_override setgid setuid sys_nice
dac_read_search audit_control };
+allow crond_t self:capability { dac_override setgid setuid sys_nice
dac_read_search };
+logging_set_loginuid(crond_t)
+logging_send_audit_msg(crond_t)
dontaudit crond_t self:capability { sys_resource sys_tty_config };
allow crond_t self:process ~{ ptrace setcurrent setexec setfscreate
setrlimit execmem execstack execheap };
allow crond_t self:process { setexec setfscreate };
@@ -117,7 +119,7 @@
term_dontaudit_use_console(crond_t)
# need auth_chkpwd to check for locked accounts.
-auth_domtrans_chk_passwd(crond_t)
+auth_domtrans_upd_passwd(crond_t)
corecmd_exec_shell(crond_t)
corecmd_list_sbin(crond_t)
[root@topaz BUILD]#
...
...
[root@topaz BUILD]# diff -uNr
serefpolicy-2.4.6-57/policy/modules/system/authlogin.fc
serefpolicy-2.4.6-69/policy/modules/system/authlogin.fc
--- serefpolicy-2.4.6-57/policy/modules/system/authlogin.fc
2006-11-29 17:04:51.000000000 +0000
+++ serefpolicy-2.4.6-69/policy/modules/system/authlogin.fc
2007-05-30 08:57:20.000000000 +0100
@@ -14,6 +14,7 @@
/sbin/pam_timestamp_check --
gen_context(system_u:object_r:pam_exec_t,s0)
/sbin/unix_chkpwd --
gen_context(system_u:object_r:chkpwd_exec_t,s0)
/sbin/unix_verify --
gen_context(system_u:object_r:chkpwd_exec_t,s0)
+/sbin/unix_update --
gen_context(system_u:object_r:updpwd_exec_t,s0)
ifdef(`distro_suse', `
/sbin/unix2_chkpwd --
gen_context(system_u:object_r:chkpwd_exec_t,s0)
')
[root@topaz BUILD]#
...
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
Hi there,
I updated my system on the 26th, and after an involuntary restart this
evening, if I have SELinux enabled, xend will not start. The errors in the
logs are the following.
audit(1180381236.512:338): avc: denied { execute } for pid=7781
comm="python" name="bash" dev=dm-0 ino=1376288
scontext=user_u:system_r:xend_t:s0 tcontext=system_u:object_r:shell_exec_t:s0
tclass=file
audit(1180381236.664:339): avc: denied { execute } for pid=7793
comm="python" name="bash" dev=dm-0 ino=1376288
scontext=user_u:system_r:xend_t:s0 tcontext=system_u:object_r:shell_exec_t:s0
tclass=file
audit(1180381237.276:340): avc: denied { execute } for pid=7797
comm="python" name="bash" dev=dm-0 ino=1376288
scontext=user_u:system_r:xend_t:s0 tcontext=system_u:object_r:shell_exec_t:s0
tclass=file
I have run a "restorecon -R /" to attempt to correct this, but it makes no
difference.
The installed SELinux packages are:
libselinux.x86_64 1.33.4-2.fc6 installed
libselinux.i386 1.33.4-2.fc6 installed
libselinux-python.x86_64 1.33.4-2.fc6 installed
selinux-policy.noarch 2.4.6-69.fc6 installed
selinux-policy-targeted.noarch 2.4.6-69.fc6 installed
I have re-installed these, just in case, and rerun restorecon. Enabling
SELinux still gives the same errors.
I am no expert on SELinux (and I failed the RHS333 exam :-/ ) and I am a bit
stumped on this one. Does anyone have an idea what is wrong and what I can
try to resolve this?
Thanks!
/Anders
syslog-ng has a /var/lib/syslog-ng, but there's no syslogd_var_lib_t
in the RHEL5 policy. So I create the below module. But, what happens
if RHEL comes out with an updated policy that includes syslogd_var_lib_t?
Should I maybe wrap the definition in a check for if it already exist ?
------------------------------------------------------------------------------
module syslog_ng 1.0.3;
# The followin two lines are what I'm asking about:
type syslogd_var_lib_t;
files_type(syslogd_var_lib_t)
require {
class sock_file { getattr unlink };
class tcp_socket { create bind setopt name_bind node_bind listen };
class dir { search write add_name };
class file { create write getattr read };
type device_t;
type syslogd_t;
type rsh_port_t;
type inaddr_any_node_t;
type var_lib_t;
type syslogd_var_lib_t;
};
allow syslogd_t device_t:sock_file { getattr unlink };
allow syslogd_t rsh_port_t:tcp_socket name_bind;
allow syslogd_t inaddr_any_node_t:tcp_socket node_bind;
allow syslogd_t self:tcp_socket { create listen bind setopt };
allow syslogd_t syslogd_var_lib_t:dir { search write add_name };
allow syslogd_t syslogd_var_lib_t:file { create write getattr read };
allow syslogd_t var_lib_t:dir search;
------------------------------------------------------------------------------
-jf
I inadvertently sent this to cpebenito(a)tresys.com rather than to the
list. Here it is for the list:
Christopher J. PeBenito wrote:
> On Wed, 2007-05-23 at 15:11 -0700, Ken wrote:
>> I became interested in SELinux primarily to increase the level of
security I have when I am connected to the Internet, and until recently
I have not allowed kernel_t to send or receive rawip over the Internet.
I have recently allowed this because I was having difficulty making
an online payment without this enabled. Since enabling this, I have
wondered what the security implications of allowing kernel_t to send and
receive rawip on the Internet are;
>
> Its normal behavior, the kernel needs the permission so can handle ICMP
> traffic, e.g. ping replies, destination unreachable, etc.
>
I am aware of ICMP traffic, but even the best programs and
protocols can be unexpectedly vulnerable to exploitation; and from a
logical perspective, I have (completely and unconditionally) opened my
system to allow a particular type of communication with outside
connections -- at least with respect to SELinux. My interest is in
learning what the logical limits are with respect to what can be sent
and received as rawip to and from kernel_t; and what the limitations of
what can be done with the data are. I was hoping there is a document
compiled somewhere that provides this (and similar) information.
- Ken -
I'm currently testing the latest rawhide build (F7), and I need help in
allowing tftpd traffic (for PXE functionality).
My previous work around solution was:
setsebool -P tftpd_disable_trans=1
But this is no longer allow under rawhide (F7). I tried running
system-config-selinux to search for any entry on tftp or tftpd, but
found none. Any other suggestion/workaround without disabling selinux?
Here is the output from Selinux troubleshooter:
Summary
SELinux is preventing /usr/sbin/in.tftpd (tftpd_t) "search" to /
(rsync_data_t).
Detailed Description
SELinux denied access requested by /usr/sbin/in.tftpd. It is not
expected
that this access is required by /usr/sbin/in.tftpd 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 /, 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
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 user_u:system_r:tftpd_t
Target Context system_u:object_r:rsync_data_t
Target Objects / [ dir ]
Affected RPM Packages tftp-server-0.42-4
[application]filesystem-2.4.6-1.fc7 [target]
Policy RPM selinux-policy-2.6.1-1.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name fiji3
Platform Linux fiji3 2.6.21-1.3116.fc7 #1 SMP Thu
Apr 26
10:17:55 EDT 2007 x86_64 x86_64
Alert Count 20
First Seen Wed 09 May 2007 02:18:14 PM EDT
Last Seen Wed 09 May 2007 02:42:14 PM EDT
Local ID 736e2428-de9a-469b-8b77-92bce3a8eacd
Line Numbers
Raw Audit Messages
avc: denied { search } for comm="in.tftpd" dev=sda6 egid=0 euid=0
exe="/usr/sbin/in.tftpd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="/"
pid=3697 scontext=user_u:system_r:tftpd_t:s0 sgid=0
subj=user_u:system_r:tftpd_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:rsync_data_t:s0 tty=(none) uid=0
I became interested in SELinux primarily to increase the level of
security I have when I am connected to the Internet, and until recently
I have not allowed kernel_t to send or receive rawip over the Internet.
I have recently allowed this because I was having difficulty making an
online payment without this enabled. Since enabling this, I have
wondered what the security implications of allowing kernel_t to send and
receive rawip on the Internet are; and I was hoping someone could direct
me to a good source for technical information about the security
implications of allowing various permissions.
