Re: New LSM patch for consideration

sdsat_private

On Tue, 19 Jun 2001 jmjonesat_private wrote:

> While I see the necessity of purely-restrictive hooks for
> assurance/verification, I believe it's short sighted to explicitly define
> ALL LSM hooks as being purely restrictive, forevermore.  It may just be a
> matter of semantics.

I think the key word here is "forevermore".  Nothing we do here
will be "forevermore."  If we want to make timely progress
in creating a useable LSM framework and if we want our work to have
any hope of acceptance into the 2.5 series, then we have to 
carefully define and limit our scope based on our goals.  And
for most of the projects represented here, our goal seems to be
supporting security modules that offer finer-grained restrictive
behavior.

> I can't help but draw a distinction between "grant[ing] traditionally 
> superuser privileges..." and being permissive, which may include
> privileges that are not "traditionally supported", potentially based on
> information that the current capabilities implementation does not take 
> into account...  

Right.  I've previously mentioned that allowing a process to override
DAC restrictions on a certain set of files rather than all files
might be a desireable feature, and that the current capable()
interface merely supports allowing a process to override DAC
restrictions on all files.  But again, we have to define and
limit our scope based on our goals.  And none of the security
modules under consideration at this point seem to require
finer-grained permissive behavior than capabilities.

> It would seem that this solution simply pushes the discussion to the
> capabilities module implementation, and by calling it "capabilities"
> implies support of the pre-existing capabilities mechanism ... without
> significant extension.
> 
> Is that a correct characterization?

It would support any permissive security module, but only at the
same granularity provided by the existing capable interface.  And
it would support fine-grained restrictive security modules.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module