On Wed, 2007-12-12 at 15:18 -0500, Paul Moore wrote: > 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 ... Sure; I find it useful to see the checks in the context of the whole operation. > 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; This helps. But this seems to be for the old networking, how does it work with the secmark stuff? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.
