[redhat-lspp] Labeled networking MLS constraints?

[Paul Moore]

Eric Paris wrote:
> On Wed, 2006-10-18 at 16:08 -0400, Paul Moore wrote:
> 
>>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.
> 
> 
> Am I summing up what you are saying correctly?  A domain has permissions
> to send and receive data from 2 sockets at different levels.  It can do
> that sharing by means of just read() from SystemHigh and then write() to
> SystemLow or it can just splice the 2 sockets together.  In either case
> we must have decided that the domain in question had permissions to
> overwrite MLS decisions (else how did it get 2 sockets at 2 levels
> usable anyway?).  If that application decides to do it using splice
> instead of some other method I don't see where that is a failure of
> anything.  setsockcreatecon() doesn't allow you to create any socket at
> any level or any TE, you still are only able to create sockets allowed
> by both TE and MLS policy/constraints.

Yep, that pretty much nails it as far as I'm concerned.

> Sounds to me like we are saying "I trust this application to be capable
> of regrading data but I don't trust it to not use splice."  
> 
> I'm not sure I see the problem...

I don't either at this point.  As I said in the first posting (way up there at
the top) it was just a concern I had at first glance; I'm not concerned anymore
since in practice only "trusted applications" will have sockets with different
contexts.

-- 
paul moore
linux security @ hp