Re: [RFC] [Stacking v4 2/3] New version of SELinux patch to support stacking

From: Serge Hallyn (serue@private)
Date: Tue Dec 07 2004 - 13:40:45 PST


On Tue, 2004-12-07 at 09:12 -0800, Crispin Cowan wrote:
> Stephen Smalley wrote:
> 
> >In thinking about this issue, I realized why
> >stacker+SELinux+capabilities doesn't work under strict policy. 
> >cap_inode_setxattr() requires CAP_SYS_ADMIN to set any attribute in the
> >security namespace.  selinux_inode_setxattr() overrides this logic,
> >applying fine-grained SELinux permission checks for the security.selinux
> >attribute and only requiring CAP_SYS_ADMIN for other attributes in the
> >security namespace.  Likewise for removexattr.  Hence, this is a case
> >where SELinux explicitly overrides the logic of capabilities and a
> >simple restrictive composition is inadequate.
> >
> As I pointed out earlier, the capable() calls are permissive, and so the 
> default restrictive composition is just wrong. It is plausible that 
> Stacker could use the DeMorgan transformation of the  default stacking 
> logic and return "permit if any of the modules permit", but I have not 
> checked that such an arrangement makes sense.

But that doesn't address this particular problem.  We're all agreed that
security_inode_setxattr() is restrictive.  cap_inode_setxattr() calls
capable(CAP_SYS_ADMIN), without giving any hint of the more fine-grained
reason why it is doing so.  The problem is that none of the other
modules know why they're being asked, and they will be asked the more
specific question later anyway, though their own mylsm_inode_setxattr
hook.

I think in a recent email I said that we wanted other modules to be able
to chime in on the rights to CAP_X, but since CAP_X is going to be
misleading anyway, I don't think that is valid.

Are there good reasons not to use the attached patch?

-- 
Serge Hallyn <serue@private>





This archive was generated by hypermail 2.1.3 : Tue Dec 07 2004 - 12:28:38 PST