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