On Tue, 23 Jul 2002, Emily Ratliff wrote: > hooks. But none of the current modules, selinux, dte, lids, owlsm > capabilities, dummy actually use the hooks. SELinux has a comment to say > that they use the CAP_RAWIO capability to handle the issue. Are these > hooks really desirable given that they might lead to easily overlooked > security bugs on non-Intel platforms? If they are really desirable, should > we warn the module writer that their module might not work as expected on > non-Intel platforms in the comment for them in security.h? The fact that SELinux presently does not use some of the "system" hooks should not be taken to mean that we don't consider these hooks to be useful. The "Controlled via the capable hook" comments in several of the SELinux "system" hook functions are merely to indicate that the operation is controlled in some manner even though the "system" hook function presently does nothing. We may later introduce separate permission checks for some of these hooks. These "system" hooks can support finer-grained control than the capability check. As you note, the iopl and ioperm hooks are architecture-specific (even differing in the ia64 case, where ioperm merely calls iopl), but I don't think that necessarily means that they should be removed. The ioperm hook could probably be implemented just as easily using system call interposition, since its parameters are simple integers (i.e. no concerns about race conditions in looking up file descriptors, pathnames, etc) and are directly accessible as system call arguments. Hence, this hook could probably be removed from i386 (and does not exist for ia64). The iopl hook does provide the old level in addition to the new level, so it is somewhat better than interposition. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jul 24 2002 - 05:34:04 PDT