Hide Forgot
Description of problem: SELinux reports different interface in the avc issued. Instead of tun0 (tun device) it reports the network interface as "lo" (loopback) which is wrong. The following is reported: time->Wed Jun 8 02:18:03 2011 type=AVC msg=audit(1307495883.629:52): avc: denied { recv } for saddr=192.xx.xx.xx src=80 daddr=10.xx.xx.xx dest=51711 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet While iptables reports this as: Jun 8 02:18:03 test1 kernel: [ 1414.984484] FW:REJECT:IN= OUT=tun0 SRC=10.xx.xx.xx DST=192.xx.xx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5597 DF PROTO=TCP SPT=51711 DPT=80 WINDOW=2920 RES=0x00 SYN URGP=0 The 10.xx.xx.xx address is on my tun0 device, not the loopback (lo) as reported in that AVC. Version-Release number of selected component (if applicable): FC13 with the latest policy applied, but I assume it would be the same with all other policies. How reproducible: Always. Steps to Reproduce: 1. set up a firewall policy to "induce" dropping or rejection of a packet originating from a tun device (which should be up and running and assigned an IP address) to an ip address:port outside the network 2. Set up (or alter) SELinux policy appropriate to an application so that it denies sending packets to outside on the same address:port range as set in step 1 above 3. Start the application and attempt to send packets to the "forbidden" destination (ip:port) which originate from the tun0 device. Actual results: time->Wed Jun 8 02:18:03 2011 type=AVC msg=audit(1307495883.629:52): avc: denied { recv } for saddr=192.xx.xx.xx src=80 daddr=10.xx.xx.xx dest=51711 netif=lo scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet Expected results: time->Wed Jun 8 02:18:03 2011 type=AVC msg=audit(1307495883.629:52): avc: denied { recv } for saddr=192.xx.xx.xx src=80 daddr=10.xx.xx.xx dest=51711 netif=tun scontext=unconfined_u:system_r:transmissionbt_t:s0 tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet Additional info:
(In reply to comment #1) > Steps to Reproduce: > 1. set up a firewall policy to "induce" dropping or rejection of a packet > originating from a tun device (which should be up and running and assigned an > IP address) to an ip address:port outside the network > 2. Set up (or alter) SELinux policy appropriate to an application so that it > denies sending packets to outside on the same address:port range as set in step > 1 above You did not show the actual policies. Just describing them is not enough - we need to see the details.
(In reply to comment #1) > (In reply to comment #1) > > Steps to Reproduce: > > 1. set up a firewall policy to "induce" dropping or rejection of a packet > > originating from a tun device (which should be up and running and assigned an > > IP address) to an ip address:port outside the network > > 2. Set up (or alter) SELinux policy appropriate to an application so that it > > denies sending packets to outside on the same address:port range as set in step > > 1 above > > You did not show the actual policies. Just describing them is not enough - we > need to see the details. I did not "describe" the policies - I described how to reproduce the bug, hence the "Steps to reproduce" heading you were kind enough to quote above. As for the SELinux policies I used - I don't see whet relevance this has on the bug I reported. An interface is reported as "lo" in the AVC issued, where it should have been reported as "tun" or "tun0" instead.
(In reply to comment #0) > Description of problem: > SELinux reports different interface in the avc issued. Instead of tun0 (tun > device) it reports the network interface as "lo" (loopback) which is wrong. > The following is reported: > > time->Wed Jun 8 02:18:03 2011 > type=AVC msg=audit(1307495883.629:52): avc: denied { recv } for > saddr=192.xx.xx.xx src=80 daddr=10.xx.xx.xx dest=51711 netif=lo > scontext=unconfined_u:system_r:transmissionbt_t:s0 > tcontext=system_u:object_r:unauthorised_packet_t:s0 tclass=packet > > While iptables reports this as: > > Jun 8 02:18:03 test1 kernel: [ 1414.984484] FW:REJECT:IN= OUT=tun0 > SRC=10.xx.xx.xx DST=192.xx.xx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=5597 DF > PROTO=TCP SPT=51711 DPT=80 WINDOW=2920 RES=0x00 SYN URGP=0 It is worth noting that the reported AVC denial message and the iptables log message are talking about two different events on the same packet. The AVC denial is referencing the reception of the packet (packet:recv permission) and the iptables log message is referencing the sending of the packet (IN=<EMPTY> OUT=tun0).
Thinking about this some more and I believe the current behavior is correct. A TUN/TAP device is not a network "device" in the traditional sense, and there is more value (from a security perspective) in knowing what the underlying real network device is when performing incoming packet access control. I'm closing this bug as WONTFIX.
My mistake, this should have been closed as NOTABUG.