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/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:27 EST