Re: Curious AVC for syslog-ng listening on non-standard TCP Port.
by Ted Rule
On Sun, 11 Jul 2010 14:01:08 +0200, Dominick Grift wrote:
> On Sat, Jul 10, 2010 at 09:36:30PM +0100, Ted Rule wrote:
>
>> In the course of trying to get a syslog-ng daemon running on a
>> non-standard TCP port on CentOS5, I came across an AVC for the port
>> which appeared
>> to already have a permission in the SELinux Policy.
>>
>>
>> We tried to make syslog-ng listen on TCP Port 5514, and as a result we
>> got the following set of audit messages:
>>
>>
>> $ sudo ausearch -ts yesterday -c syslog-ng
>> ----
>> time->Fri Jul 9 23:04:26 2010
>> type=SYSCALL msg=audit(1278713066.242:269066): arch=40000003 syscall=102
>> success=no exit=-13 a0=2 a1=bfb34210 a2=95b51e8 a3=6 items=0 ppid=1
>> pid=1713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="syslog-ng" exe="/sbin/syslog-ng"
>> subj=system_u:system_r:syslogd_t:s0 key=(null)
>> type=AVC msg=audit(1278713066.242:269066): avc: denied { name_bind }
>> for pid=1713 comm="syslog-ng" src=5514
>> scontext=system_u:system_r:syslogd_t:s0
>> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>> ----
>> time->Fri Jul 9 23:04:26 2010
>> type=ANOM_ABEND msg=audit(1278713066.291:269067): auid=4294967295 uid=0
>> gid=0 ses=4294967295 subj=system_u:system_r:syslogd_t:s0 pid=1713
>> comm="syslog-ng" sig=11
>> ----
>> time->Fri Jul 9 23:27:59 2010
>> type=SYSCALL msg=audit(1278714479.797:269169): arch=40000003 syscall=102
>> success=no exit=-13 a0=2 a1=bffe96d0 a2=97a6928 a3=6 items=0 ppid=1
>> pid=15354 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=44818 comm="syslog-ng" exe="/sbin/syslog-ng"
>> subj=user_u:system_r:syslogd_t:s0 key=(null)
>> type=AVC msg=audit(1278714479.797:269169): avc: denied { name_bind }
>> for pid=15354 comm="syslog-ng" src=5514
>> scontext=user_u:system_r:syslogd_t:s0
>> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>> ----
>> time->Fri Jul 9 23:27:59 2010
>> type=ANOM_ABEND msg=audit(1278714479.833:269170): auid=500 uid=0 gid=0
>> ses=44818 subj=user_u:system_r:syslogd_t:s0 pid=15354 comm="syslog-ng"
>> sig=11
>> $
>>
>> However, despite the fact that the AVC suggested that we needed to add
>> the permission:
>>
>> allow syslogd_t port_t : tcp_socket { name_bind name_connect };
>>
>>
>>
>> an sesearch suggests that the permission already exists:
>>
>> $ sudo sesearch --allow -s syslogd_t | grep tcp |grep name.bind
>> allow syslogd_t rsh_port_t : tcp_socket { name_bind name_connect };
>> allow syslogd_t syslogd_port_t : tcp_socket { name_bind name_connect };
>> allow syslogd_t port_t : tcp_socket { name_bind name_connect };
>> allow syslogd_t reserved_port_t : tcp_socket { name_bind name_connect };
>> $
>>
>
>
> sesearch -SC --allow -s syslogd_t -t port_t
> Found 8 semantic av rules:
> allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ;
> allow syslogd_t port_type : udp_socket { recv_msg send_msg } ;
> DT allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ; [ allow_kerberos ]
> DT allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ; [ allow_ypbind ]
> DT allow syslogd_t port_type : udp_socket { recv_msg send_msg } ; [ allow_kerberos ]
> DT allow syslogd_t port_type : udp_socket { recv_msg send_msg } ; [ allow_ypbind ]
> DT allow syslogd_t port_t : tcp_socket { name_bind name_connect } ; [ allow_ypbind ]
> DT allow syslogd_t port_t : udp_socket name_bind ; [ allow_ypbind ]
>
> ... This means that syslogd_t is only allowed to bind udp/tc sockets to ports with type port_t is booolean allow_ypbind is set to true.
>
>
>> Eventually, we repaired the situation by adding TCP/5514 as a
>> syslogd_port_t, as in:
>>
>> $ sudo semanage port -l |grep 514
>> cluster_port_t tcp 5149, 40040, 50006, 50007, 50008
>> cluster_port_t udp 5149, 50006, 50007, 50008
>> rsh_port_t tcp 514
>> syslogd_port_t tcp 5514
>> syslogd_port_t udp 514
>> virt_port_t tcp 16509, 16514
>> virt_port_t udp 16509, 16514
>> $
>>
>>
>
> Good decision
>
>
>> But my curiousity is piqued. Why did the policy deny the binding to a
>> type port_t, when the policy appeared to already allow this?
>>
>>
>> FWIW, the policy at the moment is a somewhat aged:
>>
>> selinux-policy-targeted-2.4.6-203.el5
>>
>>
>
> Because it a tunable policy rules that obviously currently is toggled to false. Piping the avc denial into audit2why should suggest that
>
> # echo "type=AVC msg=audit(1278714479.797:269169): avc: denied { name_bind } for pid=15354 comm="syslog-ng" src=5514 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket" | audit2why
> type=AVC msg=audit(1278714479.797:269169): avc: denied { name_bind } for pid=15354 comm=syslog-ng src=5514 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
>
> Was caused by:
> The boolean allow_ypbind was set incorrectly.
> Description:
> Allow system to run with NIS
>
> Allow access by executing:
> # setsebool -P allow_ypbind 1
>
>
>
Thanks for the explanation, but I must say that sesearch's -C provision
breaks the golden Principle of Least Surprise for me. Surely sesearch
run without -C,
and even more so when run without an explicit policy filename, should
only print out currently active policy rules. i.e. it should only list
those tunable policy rules which are active by reason of the state of
the corresponding boolean?
As it stands, all tunable policy rules - enabled or disabled - are
listed in sesearch's output. Hence my original confusion.
I think my vote would be for a complete deprecation of the -C option, so
that sesearch always runs as if it had been included on the command line.
Example listing for this problem:
$ sudo sesearch --allow -s syslogd_t -t port_t
Found 6 semantic av rules:
allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ;
allow syslogd_t port_type : udp_socket { recv_msg send_msg } ;
allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ;
allow syslogd_t port_type : udp_socket { recv_msg send_msg } ;
allow syslogd_t port_t : tcp_socket { name_bind name_connect } ;
allow syslogd_t port_t : udp_socket name_bind ;
$ sudo sesearch -C --allow -s syslogd_t -t port_t
Found 6 semantic av rules:
allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ;
allow syslogd_t port_type : udp_socket { recv_msg send_msg } ;
DT allow syslogd_t port_type : tcp_socket { recv_msg send_msg } ; [
allow_ypbind ]
DT allow syslogd_t port_type : udp_socket { recv_msg send_msg } ; [
allow_ypbind ]
DT allow syslogd_t port_t : tcp_socket { name_bind name_connect } ; [
allow_ypbind ]
DT allow syslogd_t port_t : udp_socket name_bind ; [ allow_ypbind ]
$
--
Ted Rule
Director, Layer3 Systems Ltd
http://www.layer3.co.uk/
12 years, 8 months
sandbox -X not (longer) working
by Klaus Lichtenwalder
Hi,
I'm running an up-to-date Fedora 12. Sandbox does not work with X:
(~) klaus@nepomuk [1103] $ sandbox bash
bash: initialize_job_control: setpgid: permission denied
bash: /home/klaus/.bashrc: permission denied
bash-4.0$ exit
(~) klaus@nepomuk [1104] $ sandbox -X bash
/usr/bin/sandbox:
'/home' is required to be a shared mount point for this tool to run.
'/home' can be added to the HOMEDIR variable in /etc/sysconfig/sandbox
along with a reboot will fix the problem.
/home is in this file, but the variable is spelled HOMEDIRS, with an
additional S
Something wrong here?
Klaus
--
------------------------------------------------------------------------
Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/
PGP Key fingerprint: BF52 72FA 1F5A 1E29 C0F8 498C C4C6 633C 2821 97DA
12 years, 8 months
Cannot turn off port forwarding for sshd
by Sergey Noskov
Hello.
I have a guest user with the guest_t domain. I want this user to connect
the network only for a few of allowed ports. It works when user connects
to the host by ssh and tries to connect network, but not when it tries
to do it using ssh port forwarding.
By default, the sshd policy allows the sshd daemon to connect any tcp
port: there is the string in ssh.if file in ssh_server_template definition:
corenet_tcp_connect_all_ports($1_t)
I comment this string and recompile the module,but port forwarding wtill
works. I also grep the tmp/ssh.tmp file to be sure, that access, i.e. to
httpd_port_t is not enabled by this module, but only dns, ldap, and a
bunch of other ports not including any http port.
This request:
sesearch -SC --allow -s sshd_t -c tcp_socket -p name_connect
gives me the same port list as in .tmp file(dns and ldap) and two
strings with those cryptic @ttr which I cannot understand.
Adding
auditallow domain port_type:tcp_socket name_connect;
makes the record in logs when I connect to forwarded port:
type=AVC msg=audit(1276082912.292:133): avc: granted { name_connect }
for pid=4872 comm="sshd" dest=80
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
Steps I do to make forwarding:
ssh -L 9234:any-www-host:80 -f -p 22 -l guest -N my-selinux-host
wget 'http://localhost:9234'
and see, that file is loaded, so port forwarding happens.
I've also tried to change the sshd_t for other name to make sure it's
not allowed directly somewhere in the base policy or other modules. It's
not.
So, I have 2 questions here:
1. Shouldn't the ssh forwarding be the boolean in the policy?
2. What should I modify now(or how to find, what to modify) to deny sshd
connects to ports at all?
--
Regards,
Sergey Noskov
12 years, 8 months
Apache/PHP mail function SELinux permissions
by Ted Rule
I've had a "problem" recently with SELinux permissions related to PHP's
mail functions. These appear to give rise to two different classes of error,
one for read permissions on the httpd_t domain itself, and one for
read/write permission on a file in the httpd_tmp_t domain.
aureport gives this:
$ sudo aureport -a |grep system_mail |head
6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116101
7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116102
17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116124
23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116136
24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116136
30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116148
31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116148
39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116168
40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116168
48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116181
Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5
Looking in more detail at ausearch we see that the httpd_t related avc
is apparently related to an "eventpoll" file descriptor, whilst the
httpd_tmp_t
avc is probably for a file created by php in /tmp.
Looking at the php source code itself, I see that it is simply opening a
temporary file containing the body of the Email and pouring it via a
pipe into an instance of sendmail via popen().
As such, it seems likely that both classes of avc's are simply file
descriptors "leaking" into the popen'ed child process running in the
system_mail_t domain.
Sadly, for other reasons, the Apache hosts are still in permissive, so
it's currently unclear to me whether the PHP mail function would fail
completely if either
of these permissions are denied in enforcing mode, but it makes me
wonder whether there would be any sense in a wider solution to leaky
descriptors which caused popen() itself to close all file descriptors
other than STDIN/STDOUT/STDERR if the popen'ed executable implies a
domain transition. Alternatively, one might envisage a set of selinux
booleans which allowed a more granular control of leaked descriptors
outside of STDIN/STDOUT/STDERR.
The other potential policy improvement would be for system_mail_t to
simply "dontaudit" denials relating to eventpoll class file descriptors
and temporary files in context *_tmp_t.
time->Sun Oct 25 13:12:48 2009
type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11
success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0
ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for
pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs
ino=129640960 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
----
time->Sun Oct 25 13:15:57 2009
type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11
success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0
ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476557.234:116102): avc: denied { read write }
for pid=22099 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:39:46 2009
type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11
success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0
ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256477986.012:116124): avc: denied { read write }
for pid=23560 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:43:04 2009
type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11
success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0
ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for
pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs
ino=129701955 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478184.954:116136): avc: denied { read write }
for pid=23802 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:52:57 2009
type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11
success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0
ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for
pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs
ino=129734033 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478777.377:116148): avc: denied { read write }
for pid=24439 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
--
Ted Rule
Director, Layer3 Systems Ltd
Layer3 Systems Limited is registered in England. Company no 3130393
W: http://www.layer3.co.uk/
12 years, 8 months
Re: SELinux and openswan
by Paul Howarth
On 07/07/10 09:55, Gerard Braad wrote:
> On Wed, Jul 7, 2010 at 4:35 PM, Paul Howarth<paul(a)city-fan.org> wrote:
>> The target contexts in most of these denials are file_t, indicating a
>> labelling problem. Has the system been run with SELinux in disabled mode
>> for some time? I'd suggest relabelling and trying again.
>>
>> Paul.
>
> After doing a rpm -qa I noted selinux-policy wasn't installed, but
> selinux-policy-targted was. Should there be a dependency between these
> two? after doing an autorelabel all seems to work properly. :-s
There is such a dependency on F-13 at least:
$ rpm -q --requires selinux-policy-targeted
/bin/sh
/bin/sh
/bin/sh
config(selinux-policy-targeted) = 3.7.19-33.fc13
coreutils
policycoreutils >= 2.0.78-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
selinux-policy = 3.7.19-33.fc13
selinux-policy = 3.7.19-33.fc13
rpmlib(PayloadIsXz) <= 5.2-1
Paul.
12 years, 8 months
SELinux and openswan
by Gerard Braad
I have an issue when running SELinux in targeted mode with openswan on CentOS 5.
On one node it works well, but another node fails with:
/bin/sh: error while loading shared libraries: libtermcap.so.2: cannot
open shared object file: Permission denied
when I try to do a 'service ipsec start'. with 'setenforce 0' the
service starts.
the output that ends up in my dmesg is:
type=1400 audit(1278489551.987:60): avc: denied { search } for
pid=1278 comm="ipsec" name="/" dev=xvda ino=2
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
and as permissive:
type=1404 audit(1278489596.565:78): enforcing=0 old_enforcing=1
auid=4294967295 ses=4294967295
type=1400 audit(1278489600.661:79): avc: denied { search } for
pid=1292 comm="ipsec" name="/" dev=xvda ino=2
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=1400 audit(1278489600.661:80): avc: denied { getattr } for
pid=1292 comm="ipsec" path="/" dev=xvda ino=2
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=1400 audit(1278489600.681:81): avc: denied { read } for
pid=1292 comm="addconn" name="libnspr4.so" dev=xvda ino=7696
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
type=1400 audit(1278489600.681:82): avc: denied { getattr } for
pid=1292 comm="addconn" path="/usr/lib64/libnspr4.so" dev=xvda
ino=7696 scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
type=1400 audit(1278489600.681:83): avc: denied { execute } for
pid=1292 comm="addconn" path="/usr/lib64/libnspr4.so" dev=xvda
ino=7696 scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
type=1400 audit(1278489600.693:84): avc: denied { read } for
pid=1295 comm="ipsec" name="sh" dev=xvda ino=25126
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=lnk_file
type=1400 audit(1278489600.697:85): avc: denied { execute_no_trans }
for pid=1298 comm="_realsetup" path="/sbin/ip" dev=xvda ino=7805
scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
type=1400 audit(1278489600.701:86): avc: denied { create } for
pid=1298 comm="ip" scontext=user_u:system_r:ipsec_mgmt_t:s0
tcontext=user_u:system_r:ipsec_mgmt_t:s0 tclass=netlink_route_socket
--
Gerard Braad — 吉拉德
Project-lead Fedora-MIPS
http://fedoraproject.org/wiki/User:gbraad
12 years, 8 months
