[redhat-lspp] Labeled networking MLS constraints?

[Paul Moore]

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