interesting group of AVCs

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2011 07:49 AM, Mr Dash Four wrote:
> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

This looks like you added a policy for transmissionbt that creates a
label unauthorized_packet_t, and you are using iptables to set these
labels.


I would surmise that:
/usr/bin/transmission-daemon is trying to recv these packets on the
loopback device and it is also executing a shell script that is
executing ipsec.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk3k+BsACgkQrlYvE4MpobNFuACgzbTAAmiGDWrSFTLalTJXcwmW
uv0AoKHO1YM8B03QcpOZUyYowvgVTxqF
=+O7P
-----END PGP SIGNATURE-----