[redhat-lspp] [Fwd: Re: RHEL5 Kernel with labeled networking]

[Paul Moore]

My apologies to the lspp list, this got dropped due to a misspelling.

-------- Original Message --------
Subject: Re: RHEL5 Kernel with labeled networking
Date: Tue, 03 Oct 2006 12:40:07 -0400
From: Paul Moore <paul.moore at hp.com>
Organization: Hewlett Packard
To: Eric Paris <eparis at parisplace.org>
CC: selinux at tycho.nsa.gov,  redhat-lssp at redhat.com,
vyekkirala at TrustedCS.com,  jmorris at namei.org

Eric Paris wrote:
> DO NOT USE THESE KERNELS ON A PRODUCTION SYSTEM!
> 
> If you go to http://people.redhat.com/eparis/RHEL5_labeled_networking/
> you should find a set of kernels based off of the Red Hat RHEL5 source
> tree.  These should include patches for 
> 
> network labeling support from Venkat
> netlabel auditing
> ipsec/secmark secid reconciliation
> netlabel secid reconciliation
> 
> I need a very fast response from everyone involved if these kernels
> 
> A) boot
> B) run without labeled networking (very very important)
> C) run with labeled networking
> 
> If you run across a problem feel free to let me or the list know.  You
> may also feel free to open a bug in bugzilla.redhat.com for the product
> choose Red Hat Enterprise Linux Public Beta and RHEL5.  If you open a
> bug for this labeled networking you can go ahead and assign it to
> eparis at redhat.com so I'm sure to see it and bug the correct people.

So far in my testing I've noticed two things related to "C" using
NetLabel and neither seem to be specific to the RHEL5 backport.  I'm
just getting a handle on both of these issues so no patches yet but I
will keep everybody up to date as things progress.

The first is a race condition with the NetLabel cache caused when
NetLabel returns a cached security attribute to the LSM layer at the
same time that the cache is being invalidated (NOTE: case "B" should not
be affected).  The result is an Oops with
selinux_netlbl_secattr_to_sid() in the stack.  I think I have settled on
a reasonable fix for this, but I want to dwell on it a bit more.  In the
meantime the workaround is to disable the cache:

 # sysctl -w net.ipv4.cipso_cache_enable=0

The second issue is more of a correctness problem in
selinux_ip_postroute_last() and selinux_skb_flow_out() related to what
NetLabel uses as it's "base SID"; the changes made in the "v3" draft of
the patch messed this up a bit.  It's important to note this shouldn't
cause any sort of panic/oops/etc. it just results in a incorrect
NetLabel context when NetLabel is configured (i.e. case "B" should not
be affected).

I'll have more information, patches, bugzillas, etc. as things progress.

-- 
paul moore
linux security @ hp


-- 
paul moore
linux security @ hp