> 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. That is fine. I included the reference to SELinux to point out that I checked to see if any of the current modules have potentially dangerous behavior in this area and I was surprise to find none of them actually using the hooks, esp. given the original design goal of only putting in hooks that projects are using. > 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. I am not necessarily calling for their removal. But, if they stay, I would just like to see something like the following: diff -ur linux-2.5.26/include/linux/security.h linux-2.5.26-new/include/linux/security.h --- linux-2.5.26/include/linux/security.h Wed Jul 24 10:14:52 2002 +++ linux-2.5.26-new/include/linux/security.h Wed Jul 24 10:17:18 2002 @@ -971,6 +971,8 @@ * Check permission before setting port input/output permissions for the * process for @num bytes starting from the port address @from to the * value @turn_on. + * Note: this hook is architecture specific, your module may behave + * differently on architectures that do not implement sys_ioperm. * @from contains the starting port address. * @num contains the number of bytes starting from @from. * @turn_on contains the permissions value. @@ -978,6 +980,8 @@ * @iopl: * Check permission before changing the I/O privilege level of the current * process from @old to @level. + * Note: this hook is architecture specific, your module may behave + * differently on architectures that do not implement sys_iopl. * @old contains the old level. * @level contains the new level. * Return 0 if permission is granted. Pick the phrasing of your choice. It just needs to indicate to the module writer that their module may have different security behavior on an Intel box vs a PowerPC box or some other architecture that doesn't implement those system calls. Hopefully, the module writers will then indicate in their documentation fairly visibly that their module will quietly make different security decisions on different platforms. This is particularly important for the open sourced modules which can easily be recompiled on the other platforms. It is the fact that these hooks can implement a finer grained control that wierds me out about them, because when the module writer takes advantage of that fact, they change the security behavior of their module across different architectures. Maybe that is obvious, but it violates my expectations and I'd feel more comfortable if it were clearly documented if it is not explicitly disallowed. Emily -- Emily Ratliff IBM Linux Technology Center, Security _______________________________________________ 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 - 10:04:45 PDT