Re: New LSM patch for consideration

chrisat_private

* Stephen Smalley (sdsat_private) wrote:
> 
> On Wed, 13 Jun 2001, Chris Wright wrote:
> 
> > This is why it seems funny to place two hooks together that are essentially
> > making the same check (since capable is a hook to the module).
> 
> I think the existing DAC+capable logic is fine, using short circuit
> evaluation to avoid unnecessary calls to capable().

Thanks, I had a feeling I was missing the obvious ;-)

> I think the issue of two hook calls on the same code path is
> unrelated to the issue of authoritative hooks.  The real issue
> is that there are an existing set of capable() calls in the kernel,
> and those calls are pervasively used by both the base kernel
> and by modules, but the interface to those calls is inadequate
> for security modules that we want to support.  So we need to insert 
> our own hook calls with finer-grained interfaces, whether we
> are being restrictive, permissive, or authoritative.  But it
> isn't practical for us to replace all of the existing capable()
> calls (especially since they can occur from modules as well as
> the base kernel), so we end up with duplication.  If we only
> insert our own finer-grained hooks and do not insert a hook
> into capable, then we lose coverage.  If we only use capable
> and do not insert our own finer-grained hooks, then we lose
> flexiblity (and the ability to support most of the modules
> under consideration).

I fully agree with this.  

What I have been doing a poor job of saying is that two successive
_permissive_ hooks feels wrong.  They both have the same purpose, and
the only reason the second hook is permissive (ok, authoritative)
instead of purely restrictive is because the first permissive hook
(in capable) has insufficient granularity.  I haven't seen a strong
call for fine granularity permissive hooks, and I think this makes
simple assurance more difficult (please speak up if this matters to
you).  I wonder if fine grained restrictive hooks (that we add) along
with coarse grained permissive hooks (via capable) are sufficient?

I certainly do _not_ have a better proposal than this one for fine
grained permissive hooks.

-chris

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