[redhat-lspp] Labeled networking MLS constraints?

[Venkat Yekkirala]

> > > When a process creates a socket through a call to 
> accept() when CIPSO
> > > tags are present on the TCP handshake packets the child 
> socket's SID is
> > > a combination of the parent socket's context and the 
> *connection's* MLS
> > > label.  All data writeen to the child socket will be 
> labeled with the
> > > socket/connection's MLS label.
> >
> > I'm confused here - assuming that it's a TCP connection and 
> the handshake
> > packets indicate that the connection's MLS label doesn't permit
> > communication with the process, what happens? Does the accept() call
> > fail, or does it succeed and the socket gets created anyway 
> (with the
> > connection's MLS label), but any attempt to read/write from 
> the socket
> > then fails?
> 
> You got it, the access check on the accept() call depends on 
> the context of 
> the current process/domain and the parent socket's type.  Due to some 
> limitations in the placement of the LSM accept hook and the 
> nature of the 
> network stack it's just not possible with the code we have 
> today to block 
> access at the accept() syscall.
> 
> We might be able to do this if we added/modified some LSM 
> hooks but I don't 
> think that is reasonable to expect in the RHEL5 timeframe we 
> are facing.

Actually, if the incoming SYN can't be received by the listening
socket, the handshake should fail at that point in time (as enforced
in selinux_sock_rcv_skb). No child sock should be created. Have you
noticed a different behavior?