On Tue, 2003-04-15 at 12:58, richard offer wrote:
> I see modules as empheral, but attritbutes as permanant. If I'm running one
> LSM module, I reboot and use a different LSM module, what happens to the
> attributes that the first module added to the file ?
>
> Either we should guarantee that modules only touch attributes they know
> about---ignoring all others (but not overwriting them), or we have separate
> namespaces for each module's attributes.
>
> Stacking modules will work with either scheme, but its seems to be that
> switching policies over a reboot could easily be broken by a scheme that
> shared a single namespace.
Thanks for your comments. It occurred to me after I sent my initial
reply that you might be thinking of a scenario where you have two
different security modules for two different environments, and you
switch back and forth between them depending on what environment you are
working in. However, I think that this scenario is fundamentally
flawed, as the two modules will end up needing to be tightly coupled in
order to provide any continuous guarantees of security and would be
better implemented as a single module that understands two (or n) states
of operation and has a mechanism for secure transitions between those
states. If you keep them as independent modules, then each module has
no way of knowing what kind of data mixing occurred while the other
module was active, so the old attributes of existing files are no longer
trustworthy, and each module has no way of knowing how to handle new
files that were created while the other module was active. You really
need the two modules to be aware of each other and to maintain
sufficient state information so that the other module can recover to a
secure initial state, at which point you might as well merge them into
one module with multiple states of operation. A single module with
multiple states of operation can also potentially support transitions on
events without a reboot (or the overhead of a full module
removal+insertion), so you have greater flexibility.
-- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency- 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 : Wed Apr 23 2003 - 22:00:18 EST