Re: SELinux "filtering" capabilities?

[Stephen Smalley <sds@tycho.nsa.gov>]

On Tue, 2017-04-18 at 15:37 -0700, Casey Schaufler wrote:
> I don't expect anyone else to have run into this
> as I am working with SELinux and Smack on the same
> machine at the same time. While there are a number
> of interactions that I can explain, I have one that
> is perplexing me. I assume something rational is
> going on, but I am having trouble tracking it down.
> 
> A process with CAP_MAC_ADMIN can change its Smack label
> by writing the new label to /proc/self/attr/smack/current.*
> If I have both SELinux and Smack enabled the write fails
> with -EPERM, indicating that the process lacks CAP_MAC_ADMIN.
> Instrumenting the Smack code verifies that, even though the
> process reports having CAP_MAC_ADMIN, the capability is gone
> in smack_setprocattr().
> 
> It seem that this could be happening in the write() path,
> or perhaps an artifact of SELinux not knowing something
> special about smackfs. I don't see anything obvious.
> Unfortunately, it is going to be somewhat difficult for
> me to claim that I have SELinux and Smack working, if not
> together, at least begrudgingly on the same system.
> 
> ----
> * The smack subdir of attr isn't upstream yet, but I hope
>   to get it there real soon.

Since smack_privileged() calls capable() rather than cap_capable(), the
CAP_MAC_ADMIN check will trigger a check by all enabled security
modules, including SELinux.  SELinux will then apply a check against
policy as to whether the current process is allowed mac_admin
permission.  This is only allowed to a handful of domains (not even
unconfined_t) because to SELinux, CAP_MAC_ADMIN means the ability to
set or get a raw, uninterpreted security context that may be unknown to
the currently loaded security policy.

I suspect that smack_privileged() should call cap_capable() instead.