Re: [redhat-lspp] NetLabel performance numbers

[Paul Moore <paul moore hp com>]

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