Re: The Demise of Simple Assurance?

pollardat_private

Crispin Cowan <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?

I'm not sure of how usefull this would be but:

1. This could be used as an oportunity to implement some debugging code:

	a. The current hooks enter the security module where a debugging
	   wrapper copies the parameters before calling the real function.
	b. After the return, the original parameters are compaired to the
	   copy.
	c. If the compairison fails, then BUG/panic/resume whatever to
	   report the bug.

2. If the debug compile flag (IFDEF ...) is not present, then the
   module would operate at full speed, and without the above a/b/c steps...
   and without detecting invalid modifications made by the module.

3. I am in favor of authorative operation:

	a. The embedded system people would be able to drop what security
	   the product doesn't need (smaller kernels).
	b. Different models of DAC protection could be tested. Consider
	   using this as part of a Java engine or a raid controller ...
	c. More varieties of MAC could be tested.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

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