[redhat-lspp] Labeled networking MLS constraints?

[Klaus Weidner]

Hello,

back in August we had a discussion about MLS enforcement related to TCP
connections - could we revisit that from the viewpoint of the current
networking code? I'm also unsure to what extent this applies to both
CIPSO and IPSec/mlsxfrm, or if they handle things differently.

Here's Paul Moore's explanation from an older discussion - I've added my
interpretations below, please correct me if I'm misunderstanding things:

On Thu, Aug 31, 2006 at 02:01:28PM -0400, Paul Moore wrote:
> When a process creates a socket through a call to socket() the socket
> takes the SID of the process' domain and the NetLabel is set based on
> that SID.  Assuming NetLabel/CIPSO is used, all data written to that
> socket will be labeled with the socket's MLS label.

So for the calls that use unconnected sockets, for example recvfrom() and
recvmsg() for UDP communication, the socket's label should always be the
same as the process label, right?

> 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?

> When packets are received and a CIPSO tag is present NetLabel generates
> a SID for the packet based on the receiving socket's context and the
> packet's CIPSO MLS label.  The packet's SID is then compared to the
> socket's SID with an avc_has_perm() call, the socket's SID is the
> subject the packet's SID is the object.
> 
> All reads/writes to and from a socket or file descriptor behave as they
> always have, the process' SID is checked against the socket/fd's SID,
> the process' SID is the subject and the socket/fd's SID is the object.

For recvmsg/recvfrom with unconnected sockets (for example UDP), that
should mean that incoming packets get dropped in the packet/socket check,
and that the read call will never fail due to missing MLS rights - it
just won't get any data. For sendto/sendmsg, the MLS check would happen at
the receiving machine, does this mean that there is no MLS enforcement
for sending packets out at this level? Will they get dropped if there is
no valid CIPSO DOI mapping or SELinux SA?

About the "all reads/writes" - does this also apply to more exotic
interfaces such as the new splice() call? For example, I didn't see an
obvious LSM hook in net/ipv4/tcp.c:do_tcp_sendpages(), but I haven't
tracked down the call chain to see if it's in another function, or if
it's even necessary.

-Klaus