* frm sds@epoch.ncsc.mil "04/16/03 09:47:22 -0400" | sed '1,$s/^/* /'
*
* 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.
I'm not sure what I was thinking, I think I was thinking about smaller
modules, say capabilities and openwall or alternatively a reluctance to
remove things that "belong" to other people...
If you attach a capability attribibute to a file under the capability
module, what happens when you use SELinux ? Under your scheme, you'd remove
the capability and write a combined attribute that included SELinux and and
if needed the capability.
Under my scheme, the capability attribute would be left alone, SELinux
would add its own, and then as its the primary module would decide whether
to use the existing capability attribute or its own "combined" attribute.
The important thing is that if you ever decide to reboot a pure capability
system that you don't have to refigure all your attributes (although you
could/should).
Extended attributes are still relatively rare that people forget to record
them when replacing a file (I do that all the time under Trusted Irix),
under your scheme they would have to record every attribute on the system
before loading a module if they every wanted to return to its prior state.
If you forgot to do it just once the consequences could be nasty.
With separate attributes, its easy to write a tool to "de-dte" a system by
removing all the DTE attributes and know that nothing else will change. But
that would be a direct user action, not an unforseen side effect.
I can see your reasons for the single attribute (known quantity for
production systems), but think its better at this stage to experiment with
multiple attributes and see how people use them before forcing everyone to
a single standard. It allows small steps rather than force everyone to make
a single large one.
* Stephen Smalley <sds@epoch.ncsc.mil>
* National Security Agency
richard.
-- ----------------------------------------------------------------------- Richard Offer Technical Lead, Trust Technology, SGI "Specialization is for insects" _______________________________________________________________________- 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:20 EST