On Tue, 2004-12-07 at 08:10, Stephen Smalley wrote:
> Yes, and I'd also suggest changing all calls to the top-level capable()
> function within SELinux, capabilities, and dummy to instead only call
> their own foo_capable() functions. Otherwise, you are likely getting
> duplicate processing by each module when using stacker.
On second thought, we are presently relying on that behavior, e.g. to
ensure that SELinux capability permission checks are also applied when
cap_ptrace or cap_bprm_apply_creds checks a capability (and SELinux does
not presently apply redundant checking in its own hooks for those
cases). Likewise, when SELinux checks CAP_FOWNER in inode_setxattr, we
expect the capability module to also be consulted. The alternative to
calling the top-level capable() function in such cases is to explicitly
duplicate the processing in the SELinux hook functions when we want this
to occur. That doesn't seem very clean, but neither does having a
ptrace_attach-> stacker_ptrace-> cap_ptrace-> capable->
stacker_capable-> {cap_capable, selinux_capable} call chain. The
current situation is also polluting our audit logs, as the capable()
check in cap_vm_enough_memory() is triggering SELinux audits on every
process (note how we explicitly avoid auditing in that case in
selinux_vm_enough_memory).
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. Under targeted policy,
restorecon is running in unconfined_t and has CAP_SYS_ADMIN, so you
wouldn't have seen the problem. But under strict policy, restorecon
normally has no need for CAP_SYS_ADMIN.
Looks like netlink_send is also going to be a problem for composition
via stacker, as the two modules will clobber one another's settings in
the NETLINK_CB(skb).eff_cap. That is a case where the lack of an
explicit security field forces sharing.
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. That's unfortunate, as
that seems like a very common usage scenario (stacking a module with the
existing capabilities logic) and also means that SELinux doesn't really
benefit in any way from having stacker around - we still have to
maintain the secondary_ops ourselves.
--
Stephen Smalley <sds@private>
National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Dec 07 2004 - 06:19:53 PST