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

crispinat_private

Matt Block wrote:

> I was under the impression that the capabilities code was seen as
> somewhat monolithic and a pain to deal with, and precisely the kind of
> thing that the LSM hooks would allow to be modularized and separated.

What the capabilities feature is seen as depends on the viewer.  Chris
Wright & I see it as a mill-stone around our necks that we have to carry
:-)

Somewhat less flippantly, it seems prudent for the acceptability of the
LSM patch that it should not cripple existing security functionality, so we
either have to leave capabilities entirely alone, or do something minimally
intrusive to allow a capabilities module.

The compromise embodied in the current code allows a module to implement
capabilities.  This is the ONLY part of the LSM interface that is
permissive or authoritative; all the other hooks are restrictive.

> Which is to say that by allowing no permissive hooks, the LSM is
> dictating the use of capabilities, or a different security policy.  And,
> again, IIRC it is a project goal that the hooks oughtn't to dictate
> policy (indeed, that the point of the project was to separate security
> policy).

Insert big long rant about dictating policy vs. advantages of
restrictive-only architecture here.

> If someone supplies a broken module, they can cause your kernel to not

By "supplies a broken module" I meant a defective module, not a malicious
one.  It is far harder to ensure that your module handle something as
dangerous as a permissive hook correctly than it is to ensure that your
module mostly doesn't crash the kernel.

> modules).  These goals point to an expanded effort along the lines of
> JMJs chaining, but also to an abundance of hooks admitting of
> permissiveness as well as restriction.

LSM is a very *practical* project.  It is *entirely* about enabling
existing security technologies that work to be easily deployed on standard
kernels.  Security research into interesting ideas is easy enough to do: go
get a Linux source tree, and hack it up to your heart's content.  But only
when said research is done, the new security model has been shown to be
effective, you want to make it widely deployable, and you can convince a
large number of people not only that what you do can't be done with
LSM as-is, but that the beneifts out-weigh the costs, would it be
appropriate to add new things to LSM.

IMHO, the priority sequence for LSM is:

  1. Finish the current rendition of LSM and get it into the 2.5 kernel (as
     Greg said)
  2. Audit
  3. Permissive hooks

Rationalle:  Security auditing has a well-founded body of research that
spells out its value.  The set of additional features that audit needs
beyond the current LSM is plausibly identifiable, and may even be small.
In contrast, permissive hooks (other than capabilities) seem to boarder on
conjecture as to whether they are worth the cost.  The only real reasons
I've heard for permissive hooks have been an oblique statement that Stephen
Smalley made once and then retracted, and the honeypots projects.

In any case, I feel much more strongly that "finish stage 1" is high
priority than I do about disputing which of audit or permissiveness is more
important.  So lets go finish stage 1, and then worry about the other
stuff.

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