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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
