On Fri, Sep 27, 2002 at 03:00:03PM -0400, Stephen Smalley wrote: > So you want to move the 'if (turn_on && !capable(CAP_SYS_RAWIO)) return > -EPERM;' from the base kernel into the security module's ioperm() hook > function, in addition to whatever additional logic the module may > implement? [Assuming for the moment that we kept the ioperm() hook, even > though that isn't likely given its current lack of use and > architecture-specific nature]. Exactly. > > If so, what about the rest of the kernel access checking logic? Do you > want all of the permission() logic pushed into the security module's > inode_permission() hook function? permission() switches into per-fs code. > Do you want the bad_signal() logic > pushed into the security module's task_kill() hook function? Only the capable() check. Unless of course we make uid/gid checking optional. Which seems like a very bad idea given the mess even with just the current LSM hooks. > That kind of > change was considered and discussed on linux-security-module long ago, but > it will yield a very invasive patch for very little gain. It also > requires cleanly separating all access checking logic from functional > logic (it is sometimes fairly intertwined) and determining exactly which > is which Umm. Clean and nicely separated code is a lot of gain. Making Linux's access clean instead of a lot more messy is a good think. Much better than any feature addition. (Unless, of course, you get paid for adding features..) > (e.g. is enforcing a read-only mount a security behavior or a > functional behavior?). For the kernel it's a functional behavior. The administrator can chose to apply it for security reasons, but that's policy and thus not the kernel's issue. > > > Show me a useful example that needs this argument. > > Do you want every process that can use ioperm() to be able to access the > full range of ports accessible by that call? If not, then you need > something finer-grained than CAP_SYS_RAWIO. But as I said, we don't > presently use this hook, and it is architecture-dependent. Okay, this does actually makes sense. Point taken. > > > And WTF is the use a security policy that checks module arguments? Do > > you want to disallow options that are quotes from books on the index > > or not political correct enough for a US state agency? > > The LSM module_initialize hook is called with a pointer to the kernel's > copy of the relocated module image with the struct module header. Hence, > the security module is free to perform whatever validation it wants on > that image prior to the execution of the init function. But if the > criteria is that there must be a specific existing security module that > uses the hook, then this one will go away too. Yes, a hook without a intree user or at least a properly defined and available out-of-tree user is pointless. _______________________________________________ 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 : Tue Oct 01 2002 - 10:07:27 PDT