Stephen Smalley wrote: > On Tue, 2006-10-17 at 08:36 -0400, Paul Moore wrote: > >>On Monday 16 October 2006 9:49 pm, Klaus Weidner wrote: >> >>>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. >> >>I can't say right now, this is the first I've heard of splice(). If there is >>no LSM hook in place at some point in the splice() stack then this is a >>serious bug not just for labeled networking but LSM and SELinux in general. > > Depends on whether you need mediation at that point, or whether the > existing checking when sockets are created, inherited across execve, or > transferred via local IPC is sufficient.
I just spent a few minutes looking at splice() and there are two things I am concerned about (anybody have any others?): 1. Application splice()'ing a socket with a context matching the domain to a socket created a setsockcreatecon() context. This could be an issue, but since setsockcreatecon() is restrcited I wonder if it would be a problem in practice. 2. Similar to #1 but in the case the non-matching socket would be created through accept() and labeled networking. This is a bit more scary as this has the potential to be more widespread than #1. However, if Venkat is right about being able to deny connections at the connection request level then this may not be an issue. If I don't hear anything back from Venkat soon about my question involving sock_rcv_skb() I'll dig a bit and report back what I find. In the meantime, if anyone wants to tell me that the above two concerns are unfounded I'll be very happy :) -- paul moore linux security @ hp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
