Re: Security through Permissiveness: A Zen Riddle?

jmjonesat_private

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

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

The advantages:

*  The interface would allow restrictive-only modules to refuse any 
   subordinate registration that had a non-NULL permissive substructure,
   or to easily implement a "no/never" set of hook functions.

*  The "GREP-TEST" would function.

*  While hooks need not be placed now, there's a logical place to 
   put them in Stage II or Stage X if they become useful.

*  Many people/organizations seem interested in working on Stage II 
   or Stage X submissions NOW and may potentially abandon LSM if their
   interests are not explicitly addressed.  The more the merrier.

The disadvantages:

* we'll go to the Kernel Developers with a few lines in our patch
  "reserved for future purposes"  of the people interested in other
  areas of interest for linux security.  These can be argued as being
  "other security interests that will be discussed before implementation." 

* we're wasting a few bytes.

The current strategy/interface addresses several needs: Linus' original
comments, the needs of many security module developers, and other
theoretical needs; the whole issue of if LSM may get accepted by the
Kernel Developers at all, and some others.  What it DOESN'T do is assure a
forward path for other interests, which is an important factor for those 
interested in "out of strategy" linux security.

I request, humbly, that the structure be changed (although it will make
extra work for me) to *explicitly* "ground-floor" other interests.

Sincerely,
J. Melvin Jones
|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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