Re: Security through Permissiveness: A Zen Riddle? (Crispin Cowan)

crispinat_private

jmjonesat_private wrote:

> On Fri, 13 Jul 2001, Chris Wright wrote:
> > i agree that a broken module is a broken module is a broken module.  yes
> > it's all kernel code.  i think crispin is referring to the simple
> > assurance property being...even if i really screw up my own access
> > control logic i am not making the kernel any less secure than it was.
> > and the only way i can really screw things up (besides the fact that i
> > have access to all of kernel memory) is in the capable call.  this isn't
> > failsafe meaning if i dereference a NULL pointer i will failsafe, this
> > is more like i won't give away the farm with one bad logic error.
> > (kinda hand wavey i know, it's friday evening ;-)
>
> This "simple assurance policy" is not necessarily true. Saying "no" is not
> always the best way... for example a "let 'em into a honeypot area until
> we figure out who they are" sort of strategy.

You're mis-understanding the "simple assurance property."  The simple assurance
property says that you can trivially show that bad logic in a module cannot
cause access controls to be made looser than they would be without the module.
It does not say that restrictive-only LSM modules are the last word in security
models.

> Example, the Ramen Virus/Worm.  There's not much to be lost by letting it
> in, telling it that it has planted the /dev/.lib files and that the rc.d
> files have been changed.  It may take 3 or 4 or 5 consecutive combinations
> of change to "trip" the security... and permitting the first 2 or 3 or 4
> will let you identify the beast.  Of course, you don't commit the file
> changes while you're looking, but "permissive" is useful/necessary here
> "to catch a thief"... and while other means may suffice in this specific
> case, the future holds other examples.

We've been over this discussion before.  We know that permissive hooks have
some utility, primarily for Capabilities and for honeypots.  We've also
collectively decided that the simple assurance property is more valuable than
the flexibility of permissive hooks, in the absence of new arguments or
issues.  You present no new arguments or issues, and just bring up the
permissive question again.  I don't understand why.

> Don't worry about Linus, or even, more abstractly, the "Kernel
> Developers"; worry about your proof. Linus ain't stupid, but he
> IS smart.  Are we working for Linus, or working WITH Linus for Linux?
> Are we trying to get just a "yes" or actually an LSM that is RIGHT?

There is no "right".  An LSM with half of the current hooks selected at random
and removed would be better than what we have now.  Almost any "yes" is better
than a "no".

This conversation (LSM stage 1 design and implementation) is intended to
prepare the best possible LSM design that we think we can get admitted to the
kernel without prior LSM experience.  Stage 2 is planned to be whatever else we
can justify, based on LSM experience in practice in Linux 2.5.

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