[redhat-lspp] Labeled networking MLS constraints?

[Klaus Weidner]

On Tue, Oct 17, 2006 at 09:18:12AM -0400, 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.

Unless I'm misunderstanding it, it sounds as if the checks are currently
not sufficient for accept(), and mediation is necessary at the read/write
level.

This is very important for LSPP compliance - if the MLS access check
would happen at the accept/connect level, a process would always have
read/write permission to all its sockets, and the calls would not need to
be considered security relevant. I think it's been a fairly pervasive
assumption that file descriptors can be used freely on the basis that the
access checks happen when they are assigned.

But if accept/connect don't do an MLS check and will return a socket to
which the process doesn't have access permission, all read/write related
calls are responsible for enforcing MLS restrictions and need audit
capability, testing, and documentation (The read(2) man page doesn't
mention EACCES as a possible error condition).  The candidates include
splice/sendfile, readv/writev, and probably others (asynchronous I/O?). 

-Klaus