[redhat-lspp] Updated NetLabel patch

[Paul Moore]

Stephen Smalley wrote:
> On Thu, 2006-06-15 at 15:16 -0400, Paul Moore wrote:
> 
>>Sorry, I typed fork when I mean fork-and-exec, I understand why you
>>wouldn't want to do a context transition on a fork.
>>
>>I guess I need to look at the xinetd sources as well as Trent's xinetd
>>patch one more time as I didn't remember xinetd doing an accept().  I
>>thought xinetd just setup a socket and waited for a select() to fire for
>>the socket and then did the fork-and-exec.  If that isn't the case then
>>this is really going to require some thought ...
> 
> You'd have to accept before you could get the peer context - peer only
> makes sense for a connected socket.
> 
> Per xinetd.conf, the wait attribute controls whether or not xinetd does
> the accept on a per-service basis, and tcp services generally use wait =
> no, which means xinetd handles accepting the connections.
> 

Thanks for the xinetd clarification, that's what I get for looking at
code too quickly, who knows, maybe I should have been a soccer player :)

>From a NetLabel point of view you could probably get the context of the
next connection waiting to be accepted on a given socket by peeking at
the icsk_accept_queue, however, I imagine there is a race condition here
 that would need to be dealt with before you could rely on it.  Yet,
even still that wouldn't solve the problem of xinetd doing the accept
and setting the socket's context and CIPSO label.

At this point I'm open to suggestions for solving this if anyone has a
thought.  Myself I may have one or two but I need to dwell on them a bit
more first.

-- 
paul moore
linux security @ hp