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