On Thu, 2007-04-19 at 09:05 -0500, Klaus Weidner wrote: > On Wed, Apr 18, 2007 at 04:20:34PM -0400, Daniel J Walsh wrote: > > Eric Paris wrote: > > >Well the implementation sees this as 2 different operations. The open > > >is taken care of entirely by standard VFS securty hooks. AKA does your > > >shell (staff_r) have permission to open a system_u:object_r:security_t > > >file with write. Apparently policy says that it does and I see no > > >reason why that couldn't be 'fixed' thus solving your inquiry. Dan? > > > > Checks in SELinux happen on read/write not on open. > > 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. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
