On Tuesday 11 December 2007 3:23:22 pm Christopher J. PeBenito wrote: > On Tue, 2007-12-11 at 12:02 -0500, Paul Moore wrote: > > After a discussion with Venkat last week we decided that it was > > probably best if I took responsibility for the flow control patches > > and ported/cleaned them up for inclusion in the labeled networking > > patches for 2.6.25. In the course of doing so I ran across the > > problem of subject/object "ordering" (probably not the best term, > > but it's all I can think of right now). In both the "flow in" and > > "flow out" cases I'm tempted to use the packet's peer label as the > > object just for the sake of consistency and the ability to use the > > new "peer" object class for all network peer label access checks. > > However, I wanted to make sure that is what everyone had in mind > > from a conceptual point of view. See the two simple policy examples > > below: > > > > * Packet "flows" into the system, peer label is the object > > > > allow netif_t peerlbl_t:peer flow_in; > > > > * Packet "flows" out of the system, peer label is the object > > > > allow netif_t peerlbl_t:peer flow_out; > > Can you give an example for the forwarding case? Also, how about in > the non-labeled networking case? Sorry, I wasn't trying to get into a detailed discussion about the policy involved in all this, but I understand it's probably necessary to get your head around it so I'll give it a shot. If you haven't yet, go read my reply to Casey first as I'll build upon that here ... First off, these access checks would only become active if labeled networking was "enabled". This means that either labeled IPsec or NetLabel has some configuration loaded. For labeled IPsec this means an entry was created in the SPD or SAD with a SELinux context assigned to it. For NetLabel this means a CIPSO DOI configuration was loaded into the kernel. If labeled networking is not "enabled" then these access checks will never happen; this was done to help reduce the impact of the network access controls on the common case. Assuming labeled networking is enabled, a forwarded packet would hit four checks: # inbound checks allow netif_t peer_t:peer ingress; allow netnode_t peer_t:peer ingress; # outbound checks allow netif_t peer_t:peer egress; allow netnode_t peer_t:peer egress; Does this help? -- paul moore linux security @ 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.
