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

[Klaus Weidner]

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.

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.

-Klaus