interesting group of AVCs

[Mr Dash Four]

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?