On 12/07/2016 10:14 AM, Paul Moore wrote: > On Wed, Dec 7, 2016 at 8:25 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: >> On 12/06/2016 07:13 PM, Paul Moore wrote: >>> On Tue, Dec 6, 2016 at 10:00 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: >>>> Extend SELinux to support distinctions among all network address families >>>> implemented by the kernel by defining new socket security classes >>>> and mapping to them. Otherwise, many sockets are mapped to the generic >>>> socket class and are indistinguishable in policy. This has come up >>>> previously with regard to selectively allowing access to bluetooth sockets, >>>> and more recently with regard to selectively allowing access to AF_ALG >>>> sockets. Guido Trentalancia submitted a patch that took a similar approach >>>> to add only support for distinguishing AF_ALG sockets, but this generalizes >>>> his approach to handle all address families implemented by the kernel. >>>> Socket security classes are also added for ICMP and SCTP sockets. >>>> Socket security classes were not defined for AF_* values that are reserved >>>> but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ASH, >>>> AF_ECONET, AF_SNA, AF_WANPIPE. >>>> >>>> Backward compatibility is provided by only enabling the finer-grained >>>> socket classes if a new policy capability is set in the policy; older >>>> policies will behave as before. The legacy redhat1 policy capability >>>> that was only ever used in testing within Fedora for ptrace_child >>>> is reclaimed for this purpose; as far as I can tell, this policy >>>> capability is not enabled in any supported distro policy. >>>> >>>> Add a pair of conditional compilation guards to detect when new AF_* values >>>> are added so that we can update SELinux accordingly rather than having to >>>> belatedly update it long after new address families are introduced. >>>> >>>> Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov> >>>> --- >>>> v2 reworks the style based on comments from Guido Trentalancia and adds >>>> security classes for SCTP and ICMP sockets. The security class support >>>> for SCTP sockets was based on Richard Haines' SCTP patch set. For now, >>>> we only duplicate the class definition for rawip_socket for SCTP and ICMP >>>> sockets since that is how they were previously mapped. The SCTP definition >>>> can be further fleshed out by the SCTP patch set itself. >>>> >>>> security/selinux/hooks.c | 73 >>>> +++++++++++++++++++++++++++++++++++++ >>>> security/selinux/include/classmap.h | 68 >>>> ++++++++++++++++++++++++++++++++++ >>>> security/selinux/include/security.h | 3 +- >>>> security/selinux/selinuxfs.c | 2 +- >>>> security/selinux/ss/services.c | 3 ++ >>>> 5 files changed, 147 insertions(+), 2 deletions(-) >>> >>> You mentioned IGMP previously, if we have a class for ICMP, it seems >>> reasonable to have one for IGMP, don't you think? Although this does >>> spiral a bit if we consider all the IPPROTO* protocols. >> >> I thought about it, but the kernel does not provide IGMP sockets per se, >> unlike ICMP or SCTP sockets (i.e. ipv4/af_inet.c:inetsw_array[] defines >> an entry for SOCK_DGRAM, IPPROTO_ICMP and sctp/protocol.c defines and >> registers inet_protosw entries for SOCK_STREAM, IPPROTO_SCTP and >> SOCK_SEQPACKET, IPPROTO_SCTP; there is no equivalent for IGMP unless I >> missed it). So IGMP sockets are just raw IP sockets with a particular >> protocol value; they have no stream, seqpacket, or dgram semantics, and >> it is unclear it is worthwhile to distinguish them in policy. > > Yes, sorry about that, it looks like you're right. I thought there > might be some sort of IGMP routing daemon or something that would need > to create an IGMP socket, but it looks like you just configure the > kernel's multicast routing table and the kernel takes care of the IGMP > packets.
Well, I think you can create an IGMP socket ala socket(PF_INET, SOCK_RAW, IPPROTO_IGMP). And we could map that to a IGMP socket class if we really wanted to do so. But that would be the first time we ever mapped a (PF_INET, SOCK_RAW, proto) to something other than SECCLASS_RAWIP_SOCKET. And at that point we'd probably want to map every individual protocol value. Not sure we need/want to go there. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
