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