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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
