Re: The Demise of Simple Assurance?

crispinat_private

Valdis.Kletnieksat_private wrote:

> On Tue, 31 Jul 2001 13:46:01 PDT, Crispin Cowan said:
> > The "simple assurance" property is something that David Wagner and I value
> > highly.  It is the idea that if there are only restrictive hooks (see amazingly
> > long preceeding discussion) then logic errors in a module cannot result in
> > system security breeches that are worse than what would happen without the buggy
>
> Or phrased differently, you want "fail-closed" rather than "fail-open" in case of a
> module *bug*, but are *not* worried about actual *malicious* code.  Am I reading
> you correctly here?

Yes, you are reading me correctly.

> >    * Do something to get the pure simple assurance property back.  This is
> >      likely to be brutally difficult, as it will involve change call-by-referece
> >      interfaces into call-by-value interfaces, which is highly unnatural in C.
> >      Not recomended.
>
> Worse than that - you need an entire marshalling scheme, because you may be passing
> in a struct by value that contains pointers to other structs, so it gets VERY ugly?

VERY ugly.  I think we can stop convincing ourselves that option 1 is not
acceptable.  I just listed it as something that is obviously desirabe but not
attainable.  It is the straw man against which other proposals are measured :-)

> >    * 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.
> Bug tolerance is a good thing..

That was the motive behind the "simple assurance" argument in the first place.  IMHO,
it still applies, but in light of JMJ's observations, it applies less than it did
before.

> OK... riddle me this:  Do any of the various contingents have security models/plans
> that would *not* be recast in terms of authoritative hooks (possibly in conjunction
> with internal programming style guides such as "always set EPERM first, and clear
> it if it SHOULD be allowed")?  Are all flavors of permissive/restrictive doable via
> authoritative, or is there some subtle issue regarding hook placement/etc?

Here's some hook placement issues that do come up, following a discussion with Chris
Wright:

   * MAC/DAC sequence:  making the hooks authoritative means universally doing the
     DAC checks first.  To be authoritative, the hook must be the very last thing
     checked before access proceeds.  SGI may not like this.
   * Being fully authoritative:  there are code paths where an early DAC check that
     fails short circuits out of the kernel.  With our current hook placement, we
     won't catch all of those short circuits out of the kernel.  Therefore, the hooks
     won't really be universally authoritative, unless we go place a lot more hooks.
     Chris is unsure of how many additional hooks would need to be placed.

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