[redhat-lspp] Labeled networking MLS constraints?

[Paul Moore]

James Antill wrote:
> On Tue, 2006-10-17 at 12:09 -0400, Paul Moore wrote:
> 
> 
>>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.
> 
>  I'm not 100% sure that splice() can do TCP -> TCP splices. The idea
> behind the API is that everything goes through a pipe(). So you'd have:
> 
> net IN -> pipe -> net OUT
> 
> ...where the pipe acts in the same way to a user space buffer (and you'd
> need two splice calls ... one acts as the read and one as the write).
>  I'd heard they'd done an "internal pipe" for disk IO -> network so that
> splice() could be directly called instead of sendfile().

I didn't walk all the code for TCP/splice so I can't say right now if that is
possibile or not (why not?) but I did walk the UDP/splice code so I know that is
possibile (at least there is code for it).

My main concern with all of this is an application splicing two sockets together
that have different contexts and then having data flow between the two sockets
without a check.  The reason I can about this is because NetLabel labels packets
based on the socket's context; if I connect a SystemHigh socket to a SystemLow
network socket I could see SystemHigh data on the network labeled as SystemLow.

However, since I think this is only possibile by using setsockcreatecon() (see
my earlier messages about accept() from this morning) I think this is not really
an issue as granting a domain access to setsockcreatecon() would be approval of
letting the application have control, i.e. we would consider this a trusted
application.

>>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.
> 
>  How would you treat read+write here? Ie. if splice fails the app. is
> going to go into a "read net IN" "write net OUT" loop. I think you have
> to treat splice the same way.

See my posts this morning about accept() - case #2 isn't an issue anymore unless
we give the domain special MLS overrides in policy.

-- 
paul moore
linux security @ hp