Re: The Demise of Simple Assurance?

crispinat_private

Valdis.Kletnieksat_private wrote:

> On Tue, 31 Jul 2001 15:43:25 EDT, jmjonesat_private said:
> > It is conceivable that a module COULD change fields in this structure
> > that would later circumvent in-kernel security checks, interfering with
> > the in-kernel checks and, likewise, with the "simple assurance argument".
> Umm.. if a module could screw with the structure, it can screw with the
> authoritative hooks.
>
> If you've got a rogue module running inside the kernel, the game is All Over,
> unless you have hardware support for "rings" or "address spaces" or the
> like so a module can run in a 'semi-priviledged' state.  I believe Multics
> allowed that, and IBM's MVS-class systems have some support for similar
> concepts.

I've chastised people on this list before for failing to acknowledge that a
rogue module in the kernel is impossible to defend against, and therefore out of
scope for the LSM project.  But I believe that JMJ is making a subtly different
point.

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
module. After much wrangling, we came to the compromise position of including
the capability hooks as the only form of permissive hooks we would accept, and
all else would be strictly restrictive hooks.

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.

From here, we have several choices of how to proceed:

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

Comments?

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