-----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@xxxxxxxxxxxxxxxxxxxxxxx
> 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-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
