[redhat-lspp] Labeled networking MLS constraints?

[Eric Paris]

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.

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...

-Eric