interesting group of AVCs

[Mr Dash Four]

Another "interesting" avc I've got - for various reasons (listed) below:

type=SYSCALL msg=audit(02/06/2011 11:52:56.270:136) : arch=i386 
syscall=close success=yes exit=0 a0=b a1=0 a2=16be30 a3=b6421c88 items=0 
ppid=1 pid=2003 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(02/06/2011 11:52:56.270:136) : avc:  denied  { send } 
for  pid=2003 comm=transmission-da saddr=10.x.x.x src=47573 
daddr=xx.xx.xx.xx dest=80 netif=tun0 
scontext=unconfined_u:system_r:transmissionbt_t:s0 
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet

What I can't figure out is this:

1. I have a "catch-all" SECMARK rule in my OUTPUT chain like this:

-A OUTPUT -m conntrack --ctstate NEW -j SECMARK --selctx 
system_u:object_r:unauthorised_packet_t:s0

What could be the reason that the label on that packet shown in the AVC 
above is "unlabeled_t", bearing in mind the iptables statement I have 
listed above? Could it be that the packet was "invalid" or is there any 
other reason?

2. The syscall indicated is "close", so should I assume that the 
connection is/was closing then? The destination address and port I 
masked above are known to me (and authorised!), so this is the only type 
AVC I now have (it happened twice in the last 24 hours or so - all with 
the syscall=close). I think I found the reasons for the previous group 
of AVCs I was getting and will post my findings as to what I think needs 
to be altered (i.e. tightened) in the SELinux targeted policy in the 
next few days.

3. The pid (which I assume is the process id) is shown in that AVC as 
2003 - is this reliable? The reason I am asking this is because at the 
time I checked, there was no process listed by that id and the program 
which caused this avc to be raised in the first place (transmissionbt) 
is still running, but its pid is different and, to my knowledge, that 
program has not been restarted!