Re: The Demise of Simple Assurance?

Valdis.Kletnieksat_private

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?

> JMJ is observing that even in some restrictive hooks, pointers to kernel objects
> are being passed.  This means that simple errors in LSM module code (e.g.
> writing "object->member = foo" instead of "object->member == foo" in an if
> clause) can result in critical damage.  JMJ is correct:  the desired simple
> assurance property is not as simple as I want it to be.

Unfortunately, without some better address-space architecture, we're kind
of stuck there ;)

>    * 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?

ASN.1, anybody? (as he quickly ducks) ;)

And even then, I'm not convinced that you can *guarantee* that a C program
can't screw things up - the best you can do is make it Very Very Hard.

>    * 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..

>    * 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.

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?

/Valdis