On 09/25/2015 11:45 AM, Dominick Grift wrote: > On Fri, Sep 25, 2015 at 11:27:48AM -0400, Stephen Smalley wrote: >> On 09/25/2015 11:15 AM, Dominick Grift wrote: >>> I am trying to clean up my network policy module but some things are >>> unclear. Could anyone shine some light (or correct me) on the below: >>> >>> 1. >>> network interface labels are no longer checked in any scenario (secmark, >>> netlabel, labeled-ipsec) and the netif isid is no longer used. >>> >>> So i can remove my netif types and associate the netif isid with a >>> context reserved for unused isids? > >> netif SIDs are used by the egress/ingress permission checks (which are only active if using peer labeling). > > so netifcon is still useful (albeit only with peer labeling) ? Correct. >>> 2. >>> Above also applies to node labels (ie. nodes are no longer checked in >>> any scenarion (secmark, netlabel, labeled-ipset) >>> >>> The question is then why is the node isid still working. And why do i >>> need to allow some processes to bind to nodes with the context >>> associated with the node isid? >>> >>> why is the node isid still used? > >> node SIDs are used in checks on bind(2) and for sendto/recvfrom checks (also only if using peer labeling). > > > so nodecon is still useful (albeit with using peer labeling) ? > > What i do not understand and find inconsistent is: why do i need to > allow processes that bind(2) to bind nodes associated with the > context associated with the node isid regardless, but nodecon is not > honored without using peer labeling Only the peer-related permission checks are enabled/disabled based on whether you have peer labeling. The node_bind check, which predates the peer labeling support, is not dependent on that. The other node permission checks are between peer labels and the node label, so they are dependent on peer labeling being active. > >>> 3. packets are checked with secmark, and you can associate different >>> packet types with different packets) > >> secmark allows local/internal labeling of packets via iptables and access control over them based on those labels. > > > So only packet labels apply to secmark The packet class is for secmark-based checks. That said, a "packet" or sk_buff logically has two labels: a packet/secmark/internal label and a peer/external label. There can even be a check between the two in the forwarding case. > >>> 4. peers are checked with netlabel, but you only need on peer type >>> (ie. you can't associate different peer types with different peers) > >> peer labeling can be based on labeled IPSEC or netlabel. >> NetLabel can only pass MLS labels across the network, although it can convey full contexts locally (see the selinux-testsuite for a configured example under tests/inet_socket or the SELinux Notebook for further examples). >> Labeled IPSEC can pass full labels locally or across the network (ditto). > > So i only need a single "peer type" (the one associated with the peer isid) Guessing you mean the netmsg isid here; that's for NetLabel only and only to provide a default user/role/type for CIPSO packets. netlabelctl can be configured to specify other fallbacks. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
