RE: [redhat-lspp] NetLabel performance numbers

[Venkat Yekkirala <vyekkirala TrustedCS com>]

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:paul moore hp com]
> Sent: Thursday, July 13, 2006 4:46 PM
> To: Valdis Kletnieks vt edu
> Cc: redhat-lspp redhat com
> Subject: Re: [redhat-lspp] NetLabel performance numbers
> 
> 
> Valdis Kletnieks vt edu 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
> redhat-lspp redhat com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
>