Re: interesting group of AVCs
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!