Re: [PATCH 2/5] Rework stubs in security.h

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2005-08-26 at 10:31 -0700, Tony Jones wrote:
> On Wed, Aug 24, 2005 at 06:20:30PM -0700, Chris Wright wrote:
> 
> >  static inline int security_ptrace (struct task_struct * parent, struct task_struct * child)
> >  {
> > +#ifdef CONFIG_SECURITY
> >  	return security_ops->ptrace (parent, child);
> > +#else
> > +	return cap_ptrace (parent, child);
> > +#endif
> > +
> >  }

With the third patch applied, it looks like this instead:
static inline int security_ptrace (struct task_struct * parent, struct task_struct * child)
{
#ifdef CONFIG_SECURITY
        if (security_ops->ptrace)
                return security_ops->ptrace(parent, child);
#endif
        return cap_ptrace (parent, child);

}

> The discussion about composing with commoncap made me think about whether
> this is the best way to do this.   It seems that we're heading towards a
> requirement that every module internally compose with commoncap.
>   
> 
> If so (apart from the obvious correctness issues when they don't) it's work
> for each module and composing N of them under stacker obviously creates 
> overhead.

Only matters if there are two or more modules that need to be used
together and both need to override/supplement the capability logic for a
given hook.  

> Would the following not be a better approach?
> 
> static inline int security_ptrace (struct task_struct * parent, struct task_struct * child)
> {
> int ret;
> 	ret=cap_ptrace (parent, child);
> #ifdef CONFIG_SECURITY
> 	if (!ret && security_ops->ptrace)
> 		ret=security_ops->ptrace(parent, child);
> #endif
> 	return ret;
> }

That makes capability part of the core kernel again, just like DAC,
which means that you can never override a capability denial in your
module.  We sometimes want to override the capability implementation,
not just apply further restrictions after it.  cap_inode_setxattr and
cap_inode_removexattr are examples; they prohibit any access to _all_
security attributes without CAP_SYS_ADMIN, whereas SELinux wants to
allow access to security.selinux if you pass a certain set of its own
permission checks.  vm_enough_memory is another problem area due to vm
accounting handled internally.

> If every module is already internally composing, there shouldn't be a 
> performance cost for the additional branch inside the #ifdef.
> 
> I havn't looked at every single hook and it's users to see if this would
> cause a problem.  I noticed SELinux calls sec->capget() post rather than pre 
> it's processing which may be an issue.

That one isn't so much an issue as the xattr ones and vm_enough_memory
case.  But more generally, if you think about moving toward a place
where one can grant privileges to processes based solely on their
role/domain, you'll need the same ability for capable and other hooks
too.  Naturally, that can't be done safely without a lot more work on
userspace and policy, but it is a long term goal.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/