Messages in this thread | | | Date | Tue, 1 Oct 2002 18:06:11 +0100 | From | Christoph Hellwig <> | Subject | Re: [RFC] LSM changes for 2.5.38 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |