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 -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Tue Dec 07 2004 - 10:45:58 PST