Re: [PATCH 1/6] NetLabel: correct improper handling of non-NetLabel peer contexts

[Paul Moore <paul.moore@hp.com>]

James Morris wrote:
> On Thu, 21 Sep 2006, paul.moore@hp.com wrote:
> 
> 
>>Fix a problem where NetLabel would always set the value of 
>>sk_security_struct->peer_sid in selinux_netlbl_sock_graft() to the context of
>>the socket, causing problems when users would query the context of the
>>connection.  This patch fixes this so that the value in
>>sk_security_struct->peer_sid is only set when the connection is NetLabel based,
>>otherwise the value is untouched.
> 
> I'll let Thomas comment on the Netlink changes, as he's been working with 
> you on them.

Hey, third times the charm right?

 ;)

> These changes otherwise seem ok.  How much testing has this had with and 
> without Netlabel enabled?

Joshua Brindle started a thread on the SELinux list which uncovered at
least two problems that I am aware of, one with NetLabel overriding the
peer's context and one with IPsec labeling returning the context from
the wrong SA (I may have the details of this wrong, Venkat posted about
this in the same thread).  This patch correct the NetLabel problem and
was tested using the simple reproducer provided by Joshua; I tested both
on a NetLabel'd and non-NetLabel'd connection and the results were
correct.  I have also tested this patch with the getpeercon() enabled
version of xinetd in FC/Rawhide; when configured to use labeled
connections and used with NetLabel the daemon is spawned with the
correct MLS label, when configured to use labeled connections and
NetLabel is not used xinetd reports an error because getpeercon()
returns an error (desired behavior as there is no network label present
for the connection).

If there is some other test you would like to see run let me know and
I'll give it a shot and report the results.

-- 
paul moore
linux security @ hp