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

From: Crispin Cowan (crispin@private)
Date: Tue Dec 07 2004 - 09:12:53 PST

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.

>Hmmm...I'm beginning to think that using stacker for
>SELinux+capabilities isn't going to be feasible, just from a semantics
>POV, not even considering performance overhead.
Which is why LSM did not have a stacker in the first place :)


Crispin Cowan, Ph.D.
CTO, Immunix

This archive was generated by hypermail 2.1.3 : Tue Dec 07 2004 - 10:45:58 PST