[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