On Tuesday 11 December 2007 12:51:18 pm Casey Schaufler wrote: > --- Paul Moore <paul.moore@xxxxxx> wrote: > > Hello everybody, > > > > 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; > > > > Thoughts, opinions? > > Networking policy is always fun to debate. I've gotten it wrong > so many times I've lost count. Let's see if I can add anything of > value. [Sorry for the delay, I was distracted yesterday] Yes indeed, hence the reason for my mail. I'm trying to get it "right" this time around ... probably a bit naive, but I'm crazy like that. > A packet appears out of the ether and is attached to a flow. If the > packet is a labeled object and the flow is a labeled object, what > is the subject? If the packet moves on out of the system (it is > being forwarded) and the packet is a labeled object, what is the > subject? Do you even have a subject/object relationship in this case? > I think that if you can identify the subject involved in flow > processing the policy implications ought to be pretty clear. If > you don't, and you have nothing but objects to deal with, it gets > painfully difficult to produce a security model that can be described > using traditional methods. Unfortunately we are talking about two different things here (although your argument above sorta fits in a strange way). I'm talking about the "flow control" patches that Venkat posted back in September and it looks like you are talking about access controls involving the kernel flow constructs. Somewhat related, but two different things. We should probably pick a better name that "flow control" as it has a tendency to get associated with the kernel flow construct and the two are different. I'm thinking of "packet ingress/egress controls" so unless anyone has any better ideas I'm gonna go with that for now ... Your post was an interesting read that I think summed up a lot of the discussions around labeled network access controls that we have had on the list but I'm going to trim it from this reply to help eliminate the "flow" confusion from the rest of the thread. However, I would like to keep discussion the subj/obj issues you talked about as that is the reason for my original email. Currently the SELinux network access controls treats packets as objects and I'm in no hurry to change that unless there is a real compelling reason. Keeping that in mind, there is a desire to add packet ingress and egress access controls and I'm trying to determine how we want to define these two new controls. The packet ingress control will be placed such that _all_ IP traffic entering the system, regardless of the destination (local or remote), will be subject to the access check. In a similar manner, the packet egress control will be placed such that _all_ IP traffic exiting the system, regardless of the source (local or remote), will be subject to the access check. In both cases, there is a user desire to have checks between the network interface (netif_t) and the packet's peer label (peer_t) as well as between the source address (netnode_t) and the packet's peer label (peer_t). With all this in mind I'm currently leaning towards the following: * packet ingress (inbound) allow netif_t peer_t:peer ingress; allow netnode_t peer_t:peer ingress; * packet egress (outbound) allow netif_t peer_t:peer egress; allow netnode_t peer_t:peer egress; You'll notice in both cases this continues the packet-as-an-object tradition while treating both the network interfaces and nodes as subjects. This seems reasonable to me, but I could be convinced to go the other way if that is what everyone else thinks is best (I really like the idea of getting all the labeled networking access controls to use the "peer" object class). With (hopefully) a better explanation this time, do you have any further thoughts/comments? -- 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.
