On Monday 01 February 2010 02:53:57 pm Paul Moore wrote: > On Monday 01 February 2010 12:44:56 pm Jason Shaw wrote: > > However, I found that my test app (with the allow rule below), could > > still read and display packet data coming in on any interface even with > > all interfaces assigned a unique peer_t using netlabelctl unlbl add. This > > was true when no explicit allow rules were added for the test app > > (running in myAPP_t). So while netlabelctl did require explicit allow > > rules for SSH to send/receive data (I beleive for sshd_t), an allow rule > > was not required to read raw data off of the interface for myAPP_t. > > > > allow myApp_t self:packet_socket { create read bind ioctl }; > > > > My understanding is that a packet socket is read at the device driver > > level. As such, is it possible that the packet socket is being read > > before netlabelctl enforcements are taking place? > > Hmm, yes, I think you've stumbled across a bug in the kernel where the LSM > sock_rcv_skb() hook is not called for AF_PACKET. I need to take a look and > verify the rest of the packet families and work up a fix. A quick follow up on this: after some thought and discussion, I don't think there is anything practical solution to the lack of per-packet receive controls for sockets with address families other than AF_INET and AF_INET6. The problem lies in the fact that we need to parse the IP headers, and sometimes even perform the necessary IPsec processing, to determine the packet's peer label; if the packet is arriving on a AF_INET[6] socket this work is done for us by the kernel's normal network stack processing prior to SELinux enforcing the receive side per-packet access controls, for all other address families this work is not done which means SELinux would have to implement its own packet processing. Needless to say this is not a very practical solution and would almost certainly be rejected from the mainline kernel. However, if we step back and think about this for a minute, I don't believe this is a major shortcoming. Packet sockets, by their very nature, are fairly dangerous from a network security point of view since you are essentially providing applications direct access to the network. Sure, there are cases where this is useful, but mostly from an administrative or diagnostic point of view, I struggle to find a reason where a "normal" user would need access to a packet socket. My recommendation is to restrict which domains can create and use a packet socket to only those domains which are carefully restricted and not worry about the per-packet access controls. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.