Re: Security through Permissiveness: A Zen Riddle?

chrisat_private

* jmjonesat_private (jmjonesat_private) wrote:
> On Fri, 13 Jul 2001, Crispin Cowan wrote:
> 
> > As I understand Shane's original request, it is to get away from the
> > UNIX all-or-nothing "root" security model, without totally throwing away
> > UNIX.  
> 
> It seems to me that this is most easily done with a wrapper application
> that setuid's root then drops all privs but the necessary ones based on
> some policy.  Of course, this goes to the granularity of the ability to
> drop privs.  At this point in history, the granularity is not too fine.
> 
> Heaven help the person who is using a setuid wrapper that has "holes."
> 
> A permissive interface, right now, is a big leap.  I agree (after
> significant consideration) that the "restrictive-only" case is the best
> way to proceed FIRST, but am somewhat concerned about the implication 
> that other security strategies will never be tackled.
> 
> Going back to one of my previous suggestions: wouldn't it still be fairly 
> simple and useful to move
> 
>     security_ops->
> 
> to 
> 
>     security_ops->restrictive->
> 
> and allow other submissions for potential 
> 
>     security_ops->permissive_ops->
>     or even
>     security_ops->authoritative_ops->

i don't see that this buys us anything.  we know we have divided policy
decisions into these camps.  placing blank placeholders don't seem to
add any value.  let's get something working with the work we have done.
the trick, as i'm sure you already know, is not adding the hook to the
interface, but placing it in the kernel.  we have enough work placing
the hooks we have identified now.  focus...capabilities gives us
guidance (and placement) for permissive hooks.  all new hooks are
restrictive, and geared towards access control of kernel objects.  to
this end we should be looking for kernel objects that are not covered
and hook placements that are incomplete or buggy...

we will have a much more convincing story that we are competent when we
have implemented the hook set that we are focused on right now, and have
some security modules working with it.

> 
> hooks in the future... perhaps after the original set of restrictive hooks
> is accepted into the kernel,
> 
> Also, along these lines, move all capabilty-specific functions to 
> 
>     security_ops->capabily_ops->

and security_ops->SELinux_ops->
and security_ops->Janus_ops->
and security_ops->LIDS_ops->
and security_ops->SubDomain_ops->

i disagree with this approach.

-chris

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