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