Research
Skip Research Menus
Research MenuSecurity Enhanced Linux What's New Frequently Asked Questions Background Documents License Download Participating Mail List Archives Remaining Work Contributors Related Work Press Releases Information Assurance Research NIARL In-house Research Areas Mathematical Sciences Program Sabbaticals Computer & Information Sciences Research Technology Transfer Advanced Computing Advanced Mathematics Communications & Networking Information Processing Microelectronics Other Technologies Technology Fact Sheets Publications Related Links |
SELinux Mailing ListRe: Network flow controls and subj/obj ordering
From: Paul Moore <paul.moore_at_hp.com>
Date: Wed, 12 Dec 2007 15:08:26 -0500
[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 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:
allow netif_t peer_t:peer ingress;
allow netif_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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.Received on Wed 12 Dec 2007 - 15:08:40 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |