Re: The Demise of Simple Assurance?

crispinat_private

jmjonesat_private wrote:

> On Tue, 31 Jul 2001, Crispin Cowan wrote:
> >    * Shrug.  Ok, so the simple assurance property is not as simple as we would
> >      like.  Tough noogies :-)  We still get a measure of bug tolerance from the
> >      strictly restrictive nature of the LSM interface.
>
> Agreed.  But no further "simple assurance" arguments should be allowed. The
> question is: should we reconsider previous arguments that used this as a "trump
> card?"  I think we should.

I think you have this remark in the wrong category :-)  The "Shrug" approach says, as
Wagner posted, "well, yes, there is that problem, but simple assurance still has
value."  It does NOT say that we will disregard the simple assurance property in the
future.

> >    * Give up. In for a penny, in for a pound.  Since we don't really get simple
> >      assurance, give up completely on this concept, and start using
> >      authoritative hooks.  This will (apparently) satisfy some needs of JMJ,
> >      possibly alleviate the MAC/DAC sequence tension between SGI and WireX,
> >      enable honeypot modules, and perhaps even make some other folks happy.  The
> >      cost is that the security requirements for buglessness in LSM modules goes
> >      waaay up, for *every* module.

This is where the "no more simple assurance" idea should go.

> This is NOT Giving Up.

I meant "give up on simple assurance."  Of course it is not giving up on the project.

> Authoritative hooks are generally useful and modules that need the "simple
> assurance" argument can use a stacked module that guarantees it.

That's an interesting idea.  However, in trying not to change too many variables at
once, I think it's important that this idea not mandate any additional substantive
changes to the LSM interface itself.  JMJ, do you believe that your "simple assurance
preserving module" can be made stackable without additional LSM changes?

> I'll put resources into writing it, since having an open source module allows more
> assurance.  This is NOT impossible, but it is not possible (imho) within the
> hooks/interface without tripping the "more invasive" trap that has ALSO been sprung
> many times.

Could you elaborate? Does going authoritative do the job?  What else do you need?

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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