Re: permissive vs. restrictive issue and solutions...

chrisat_private

* Stephen Smalley (sdsat_private) wrote:
> 
> On Mon, 4 Jun 2001, Crispin Cowan wrote:
> 
> > That's interesting.  "kick capabilities out" was popular with WireX engineering at
> > last week's weekly meeting, and with David Wagner.  The remaining request for
> > permissive controls is Casey's, but he hasn't said much about it.
> 
> Just to be clear, I'm not really suggesting that we "kick capabilities
> out".  Here is what I am proposing:
> 
> 1) We leave the existing capabilities module alone, but we revert the
> calls to capable() in the kernel.  The capable() function remains
> as a stub that calls the LSM capable() hook (or, better, we
> use a script to globally replace all calls to capable() with a
> direct call to the hook).  We also replace the capabilities system calls
> with stubs that call LSM hooks, and move their functionality into the
> capabilities module.  

What do we do with complex logic like (arch/i386/kernel/ptrace.c):

if(((current->uid != child->euid) ||
   (current->uid != child->suid) ||
   (current->uid != child->uid) ||
   (current->gid != child->egid) ||
   (current->gid != child->sgid) ||
   (!cap_issubset(child->cap_permitted, current->cap_permitted)) ||            
   (current->gid != child->gid)) && !capable(CAP_SYS_PTRACE))
      goto out_tsk;
rmb();
if (!child->dumpable && !capable(CAP_SYS_PTRACE))
   goto out_tsk;

The problem here is with the call to cap_issubset, and how deeply it is
embedded in the logic.  The lsm ptrace hook actually allows for the
cap_issubset() call because it takes both child and parent
task_structs.  To use the hook would really mean pushing all of this
logic into the capablilties.  To leave the capable calls means either
leaving cap_issubset (and consequently leaving the capabilities bits in
the task_struct as opposed to pushing them into the task security blob)
_or_ exposing cap_issubset in the lsm interface (or creating something like
it...you may recall some ugly hack I had in the earlier interface that
supported a generic way to compare credentials).

The compute_creds function (fs/exec.c) is another example of how
capabilities is inbred with the kernel.  That's why I took the easy
approach on that function and pushed the whole thing into the module.

> This supports the following desireable goals:
> a) People who don't like capabilities can easily use a superuser
> module in place of the capabilities module.

Seems reasonable, although capabilities is essentially a superuser check
since people rarely actually set any capabilities.  I'm not sure we need
to support two modules.

> b) The capabilities developers can easily evolve the implementation
> of their core logic without involving the kernel developers.  In
> particular, they should be able to provide their new logic with
> real file system capabilities as a module (assuming they can get
> the corresponding file system support adopted in some way).

This does seem useful.

> c) Both the superuser module and the capabilities module only
> need to implement the capable hook and the hooks related to
> execve processing and the capabilities system calls.  All
> other hooks can simply return 0.
> d) Other module developers can support DAC overrides using methods 
> other than superuser or capabilities (e.g. Type Enforcement) by
> implementing their own capable() hooks.

Limited of course to the course granularity provided by linux privs (I
believe that was 29 different capabilities with CAP_SYS_ADMIN being the
least useful abstraction).

> e) Kernel code modifications related to capabilities are minimized 
> and localized.
> 
> 2) All LSM hooks other than capable() should be used authoritatively.
> If a LSM hook can be easily placed at the same location as the
> existing logic, then the LSM hook can take an additional parameter
> to give it the option to override the kernel's logic, in which case
> it can be used either restrictively or permissively.  If not,
> then LSM hook can only be used restrictively.  

I just want to make sure it is clear that this is approach is an
official endorsement for maintaining two sets of hooks in the lsm
interface (a restrictive set and a permissive set).  Is that what we
want?

-chris

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