RFE: add LSM/SELinux access controls for AF_PACKET sockets

[pcmoore]

Add more general IPv4 and IPv6 per-packet access controls, including support for traffic over SOCK_RAW sockets.

[stephensmalley]

Aren't the existing per-packet controls via sock_rcv_skb and the SELinux netfilter hooks already covering raw IP socket traffic?

[pcmoore]

Some general comments from a brief investigation I did several years ago:

Just as a FYI: there may actually be two issues here, AF_INET{6}/SOCK_RAW
sockets, and AF_PACKET/SOCK_RAW sockets.

One possible solution for AF_INET/SOCK_RAW, and other protocols not caught by socket
filters, would be to move the selinux_inet_sys_rcv_skb()/ingress filtering into a
NF_INET_LOCAL_IN hook (all the IP processing/parsing we care about is finished at that
point) while keeping the peer object class checks in the socket filter hook.  This should
also work for AF_INET6/SOCK_RAW.

For AF_PACKET sockets, the AF_PACKET code implements its own socket filter
wrapper, af_packet.c:run_filter(), which does not call security_sock_rcv_skb() like the
normal sk_filter() function used by everything else, e.g. TCP/UDP.  The AF_PACKET
code, af_packet.c, registers a protocol handler directly with the network device, and
receives packets directly from the interface.  The IP stack is not involved (as you
would expect).

There might be some interesting policy implications here as we would end up seeing
more/new traffic that we haven't seen previously in the SELinux hooks.

[pcmoore]

Quick update: it appears that AF_INET/SOCK_RAW (and likely other protocols) end up calling sk_filter() via sock_queue_rcv_skb() so we may be in better shape than originally thought.

[stephensmalley]

Should we close this since AF_INET SOCK_RAW is covered, or edit it to instead refer to the lack of controls on AF_PACKET traffic?

[pcmoore]

Should we close this since AF_INET SOCK_RAW is covered, or edit it to instead refer to the lack of controls on AF_PACKET traffic?

Yep, we should, and I just did.

I'd like to keep this open because I dream of someday fixing this.

[stephensmalley]

Dropping some notes from an old email here for future reference on the AF_PACKET problem:

Tracing tcpdump, I see that it is using mmap'd packet sockets, as described in Documentation/networking/packet_mmap.txt.  Sequence is create a packet socket, bind() to a network interface, use setsockopt() to set up the receive ring, mmap() the ring into memory, and then use poll() to detect when to read from the ring.  And for writing (not done by tcpdump by default at least), they also setup a TX ring via setsockopt() and it is mapped directly after the RX ring by the kernel
on the same mmap() call.

As soon as you create the socket (packet_create), it registers a protocol handler (register_prot_hook -> dev_add_pack) if you specified a protocol (which tcpdump does, using ETH_P_ALL to get them all).  So any packets received after socket creation will trigger a call to packet_rcv() for SOCK_RAW (as used by tcpdump) or packet_rcv_spkt() for SOCK_PACKET (obsolete).  packet_rcv() calls run_filter() which directly dereferences sk->sk_filter and calls bpf_prog_run_clear_cb(), not using sk_filter() and therefore not calling our hook.  packet_rcv_spkt() calls sock_queue_rcv_skb() so that
path does call our hook, but that is obsolete/deprecated so not helpful.   So we'll start receiving packets in the socket receive queue for all interfaces as soon as we create the socket (unless the caller specifies protocol 0).  Caller can read those packets via recv() or read() immediately.

On a bind() call, if the protocol or device is changing as a result of the bind, we unregister the protocol handler and then re-register with the new information.  So after the bind() call, packet_rcv() will only
be called on packets matching the new protocol/device information, but AFAICS we aren't discarding the previously received packets and nothing prevented the process from reading them earlier.

On the setsockopt(...PACKET_RX_RING...) call, we again unregister the protocol handler, purge the queue, and then re-register, except that it looks like we'll use tpacket_rcv() as the handler instead (at least with the inputs provided by tcpdump for setsockopt).  tpacket_rcv() like packet_rcv() calls run_filter() and never calls our hook.  It copies the skb into the ring buffer.

Seems like the only way to reliably control what interfaces we can receive from is to hook packet_rcv() and tpacket_rcv() at the same point they call run_filter(), or hook run_filter() itself (but it isn't passed the dev argument from *packet_rcv - can this differ from skb- > dev?).

[redbaron]

CVE-2020-14386 (https://www.openwall.com/lists/oss-security/2020/09/03/3) cannot be mitigated by SELinux policy :(

[stephensmalley]

Creation of AF_PACKET sockets can be controlled by SELinux policy. This GitHub issue is just about per-packet send/receive controls for AF_PACKET.

[stephensmalley]

So to successfully exploit that CVE, a process running domain foo would require allow foo self:packet_socket { create write }; in addition to allow foo self:capability net_raw; or allow foo self:cap_userns net_raw;.