interesting group of AVCs

[Mr Dash Four]

> 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.
>   
No, all packets are classified and allotted to each domain.

transmissionbt_t can only send/receive transmissionbt_packet_t and 
transmissionbt_control_packet_t. All packets coming in and out of all 
interfaces are labelled accordingly via iptables (using the SECMARK 
target) and because of the nature of the iptables packet labelling 
(first match does *not* win), at the beginning of the marking (at the 
"top") I have a catch-all "match" which labels all packets with 
"unauthorised_packet_t" label.

Not a single domain in my policy is authorised to access that sort of 
packet, hence the first AVC (173) - this is also evident from the source 
and destination ports as they do not match anything I defined in my 
"secmark" policy, so the "catch-all" mark kicked in and stopped this 
from progressing further, issuing the AVC in the process, I think.

> 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.
>   
This is a worrying development if that is indeed the case. What I still 
cannot figure out is how a packet from outside, which could only arrive 
on 3 possible interfaces on that machine - eth0, eth1 and tun0 - ended 
up in the loopback interface?! The loopback is internal interface and 
cannot receive packets from outside at all - it is physically impossible!

Also, would it be possible to find out what shell script has been 
"executed" (I take it that has also been stopped?) and what was the 
command line of the ipset execution attempt (I also take it that wasn't 
successful either)?

I looked at the transmissionbt_t policy and there isn't a permission to 
execute the shell as well as any files within iptables_exec_t domain 
(ipset executable is a member of such domain type), so I do not 
understand how did transmissionbt_t managed to start these (if that was 
indeed the case!), let alone (attempted to) receive any packets using 
these?!

That was a fairly good hacking attempt I take it?