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

chrisat_private

* Stephen Smalley (sdsat_private) wrote:
> 
> On Tue, 5 Jun 2001, Chris Wright wrote:
>
> 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;
> 

Hmm, I like this.  Thanks.  I've looked at it numerous times and it
always gave me a headache ;-)

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

Yeah, this is what I'm a tad nervous about.  We start having multiple hooks
in the same area doing roughly the same checks.

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

No, that's not what I meant.  Two flavors of hooks.  The capable() hooks
being permissive/authoritative, and our additional hooks being
restrictive/authoritative.  I am only concerned about the clarity of the
interface since people need to be able to make sense out of it and code
to it.  I like the idea of building some kind of uniformity into the
interface.

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

My thoughts exactly! ;-)

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

How do we define which hooks take an extra parameter and get to override
the DAC checks?  And once we go this route, is there any benefit to mixing?
Why not just use approach #3 and give all hooks the option (forever in search
of a uniform interface ;-).  This could allow capabilities to stay in the
kernel as is.

-chris

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