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

sdsat_private

On Tue, 5 Jun 2001, Chris Wright wrote:

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

Good question.  Fortunately, it appears that the only cases where
we have such logic are ptrace and execve/compute_creds (plus
the capability system calls, but we can easily move their
entire implementation into the hook functions).  So in
these two cases, I would advocate separating out the
code that expresses the real capabilities logic and moving
it into the module.  The ptrace hook function can perform
the equivalent of:

    if (!cap_issubset(child->cap_permitted, current->cap_permitted))
        && !capable(CAP_SYS_PTRACE))
        return -EPERM;
    else
        return 0;

And we can change the base kernel logic here to:

  if (security_ops->ptrace(current, child))
	goto out_tsk;

   <intermediate code deleted>

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

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

True, but we can add our own authoritative hooks to support finer-grained
distinctions.

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

There won't be one set of hooks that are restrictive and
one set of hooks that are permissive. The capable() hook
has different usages (permissive or authoritative) depending
on the capability.  If there is some DAC logic for an operation,
then the capable() hook is used permissively - it can grant
a permission that would be denied by the DAC logic, but it
cannot deny a permission that would be granted by the DAC logic.  
If there is no DAC logic for an operation, then the capable() hook
is used authoritatively - it must approve the operation.
That isn't surprising when you think about the fact that
the capable() function is simply replacing the superuser
tests.  The other LSM hooks will always support restriction, but 
some of them will have the option to be permissive as well by
using an additional parameter.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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