I would encourage people to look at the following (posted a couple weeks back also) that covers the sid reconciliation aspect as well as the gamut of Labeled Networking for SELinux:
http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2 > -----Original Message----- > From: Paul Moore [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 13, 2006 4:46 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [redhat-lspp] NetLabel performance numbers > > > [EMAIL PROTECTED] wrote: > > On Thu, 13 Jul 2006 17:07:32 EDT, Paul Moore said: > > > >>No, but I don't think anyone has tried yet. That's my next step (at > >>this moment I'm trying to fix something I broke during the > last round of > >>comments) but I don't expect that to be any more of a problem them > >>trying to reconcile the existing jumble of networking hooks. > > > > I'll look at that this weekend as well - a quick 5-minute overview > > seems to indicate that there won't be any major code collisions, and > > Klaus Weidner's "toy policy module" shouldn't conflict on > the SELinux side. > > > > Thanks, any and all feedback is greatly appreciated. > > I'm running my latest 2.6.17 based code through some testing and the > machine is still running when I get in tommorrow I'll post > those patches > and move on to porting to 2.6.18-rc1. With a little bit of luck I'll > have something working by the end of the day on Friday and posted to > netdev before OLS. > > If it's looking like I won't get the 2.6.18-rc1 port done before OLS I > just go ahead and post the 2.6.17 based patch to netdev. > > > Where it gets interesting is that somebody has to go through all the > > combinations (both off, both on, etc), and make sure the > SECMARK tags > > added via iptables and the CIPSO tags added via netlabelctl interact > > correctly. In particular, Klaus's module has some 'allow > {...}' lines > > in them - we need to make sure that those don't > short-circuit and let > > through a packet that would have failed because none of the SECMARK > > rules for foo_packet_t would allow the packet, and vice versa. > > What I am planning on doing, and what the patch currently > does, is make > the NetLabel access checks additive - you'll have to make it through > SECMARK, XFRM, and NetLabel before you see the packet. A bit of a > headache that should be fixed in the future, but it should prevent the > problems you mentioned above. > > -- > paul moore > linux security @ hp > > -- > redhat-lspp mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/redhat-lspp > -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
