After routine check of my audit logs this morning I found this (capture
with ausearch -i -m AVC):
----
type=SYSCALL msg=audit(30/05/11 01:42:21.687:173) : arch=i386
syscall=socketcall(connect) success=no exit=-115(Operation now in
progress) a0=3 a1=b6dfeb40 a2=55ee30 a3=0 items=0 ppid=1 pid=4308
auid=root uid=_transmission gid=_transmission euid=_transmission
suid=_transmission fsuid=_transmission egid=_transmission
sgid=_transmission fsgid=_transmission tty=(none) ses=1
comm=transmission-da exe=/usr/bin/transmission-daemon
subj=unconfined_u:system_r:transmissionbt_t:s0 key=(null)
type=AVC msg=audit(30/05/11 01:42:21.687:173) : avc: denied { recv }
for pid=4308 comm=transmission-da saddr=xx.xx.xx.xx src=80
daddr=10.x.x.x dest=39322 netif=lo
scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:24.697:174) : avc: denied { recv }
for pid=5716 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322
netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:30.707:175) : avc: denied { recv }
for pid=5820 comm=ipset saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x
dest=39322 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
type=AVC msg=audit(30/05/11 01:42:42.727:176) : avc: denied { recv }
for pid=6068 comm=sh saddr=xx.xx.xx.xx src=80 daddr=10.x.x.x dest=39322
netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0
tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet
----
A couple of interesting things:
1. "saddr" is address outside any of my network, so I presume this is
coming in (the avc is "recv"). The destination address, however, is on
one of my interfaces (tun device). What baffles me is that "netif" field
says "lo" which would suggest the loopback interface. How is that possible?
2. The first AVC (173) refers to an attempt at receiving a packet from
outside and this was thwarted (success=no) by my iptables/selinux
packing mechanism. The following 3 AVCs however, have more sinister
look, I think, because they come from two *different* executables:
"comm=sh" (which suggests the command shell?) and "comm=ipset"
(suggesting the ipset command I have on the system). Does that mean an
attempt was made at executing these programs as well as an attempt to
receive packets using these? These 3 logs are a complete mystery to me
as neither the shell (sh) nor ipset have capabilities of sending or
receiving packets over the wire!
3. According to the last 3 logs (174-176), an attempt at receiving
packet was made (and denied) by these executables ("sh" and "ipset")
using destination address of my tun interface (10.x.x.x), but the
interface indicated in those logs is "lo". How is that possible?
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
