On Thu, 14 Jun 2001, Stephen Smalley wrote: > > On Thu, 14 Jun 2001 jmjonesat_private wrote: > > > Authoritative combines the needs of audit, permissive, and restrictive. > > I'd think if we move to restrictive-only we need to come up with a general > > solution for permissive and audit, as well, even if it largely "remains to > > be implemented." This will add more potential hooks into the core-kernel, > > but dramaticly clarifies the placement of hooks and their function, and > > presents the *possibility* of something like a "grep" verification. > > I think the view being taken by people who favor restrictive-only is > that it is sufficient to hook capable() to provide permissive support. > That provides a coarse-grained form of permissive behavior. As far > as audit goes, we'll hopefully gain some insight from SGI as to what > that truly requires. > I think thinking of permissive support in terms of "no more than already provided" is also "philosophically-"restrictive, so it would follow the "restrictive-only" group would want to impose that. If "A" is a place where no kernel security is supported, "B" is a place where DAC+Capabilities is supported, and C is a place where only more-restrictive (DAC+Capabilities and OTHER) policies are applied, then A<B<C. There are both finer grained and "otherly active" permissive considerations possible. I think if we're going to be the "definitive" kernel security interface, then we have be "definitive". :) I'm looking forward to the insight from SGI, but am concerned it may be evolution along the "capabilities" line, instead of starting an "LSM line" solution... apologies, Casey... but I am of the opinion that providing permissive-only LSM-line solutions could eventually eliminate capabilities (as previously implemented) completely, replacing it with comparable functionality under the LSM module interface. (redundant, can we separate "LSM interface", and "LSM hooks" and "LSM module" some more usable way?) If I'm wrong, I'd still rather see "capabilities-line" solutions isolated in the interface, toward future supercession. > > If the 10 calls that were changed to add kern_retval in dummy_ are truely > > representative of everywhere the kernel has an opinion that we can grab, > > then the kernel is much less opinionated than I'd thought :), and the > > impact is quite minimal. > > I only made hooks authoritative when the kernel logic was easily > colocated and decoupled from the functional logic. So there are > many other cases where the kernel has an opinion. Okay. But your solution does suggest how "easy" it will be. Apparently, not "very" iff there are lots of other "non-colocatable" places. My following of the code doesn't find it too difficult (although, somewhat difficult... especially in a few spots) or too many places where it may be useful-but-difficult. Did you enumerate (or count) the "not-easy" places? > > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Thu Jun 14 2001 - 13:36:41 PDT