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