[redhat-lspp] write access to /selinux/avc/cache_threshold

[Stephen Smalley]

On Thu, 2007-04-19 at 11:21 -0500, Klaus Weidner wrote:
> On Thu, Apr 19, 2007 at 11:40:16AM -0400, Stephen Smalley wrote:
> > On Thu, 2007-04-19 at 09:05 -0500, Klaus Weidner wrote:
> > > Argh, that approach would be a major problem for the LSPP evaluations...
> > > When we were classifying the security relevance of system calls, the
> > > basic assumption was that the security critical check happens when
> > > opening the file, and any additional checks for read/write add additional
> > > restrictions that aren't relevant for LSPP compliance.
> > > 
> > > Based on what Eric says, that should at least be the case for the MLS and
> > > object type based checks, since the full information about the labels is
> > > available to the open() check. 
> > > 
> > > I'm not convinced that the read()/write() checks are reliable since there
> > > are multiple alternative interfaces such as splice(), and for example I
> > > didn't see an obvious LSM hook in net/ipv4/tcp.c:do_tcp_sendpages().
> > 
> > SELinux does check generic read/write against the inode at open time,
> > but the per-operation checks for e.g. selinuxfs operations happen within
> > the selinuxfs implementation on read/write.  And those aren't bypassable
> > - they aren't happening in the vfs but in the actual underlying
> > operation.
> 
> Thank you for the clarification - would it be fair to say that all
> objects that contain or transport user data (including network sockets)
> are guaranteed to have a check at open time? That would be the most
> important thing for the evaluation.

Well, we always apply a check upon open(2) via the
selinux_inode_permission() hook function between the task and the inode.
Not sure what you are looking for in the case of objects that don't use
open(2), like sockets and System V IPC.  In the socket case, we don't
know information about the peer's label until we get a packet from them,
so we can't do it up front.  In the IPC case, we hooked ipcperms() to
parallel the mode-based checks there and also added hooks throughout to
ensure that we had a MAC check whenever they had an ownership check.

We also recheck upon descriptor inheritance across execve (if the label
is changing) and upon descriptor transfer across local IPC.

> If administrative interfaces such as /selinux or /proc/self/attr/ have
> different semantics I guess we can live with that, since they do not
> contain arbitrary user data that would need to be covered by the MLS
> policy. The administrative actions would then be controlled during the
> actual operation, and it's an implementation detail that this happens
> during write() calls.

I don't think selinux is unique in applying more specific checks within
its read/write methods; I think you'll see the same kind of thing in
other filesystems and drivers for DAC and capability checks (e.g. proc
has to apply its ptrace checking at read/write time).

-- 
Stephen Smalley
National Security Agency