From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v3JHtJf4019446 for ; Wed, 19 Apr 2017 13:55:25 -0400 Subject: Re: SELinux "filtering" capabilities? To: Stephen Smalley , LSM , SE Linux References: <82d9ff60-6850-0873-1e68-20bd0e27e9ee@schaufler-ca.com> <1492603104.31458.1.camel@tycho.nsa.gov> From: Casey Schaufler Message-ID: <62698386-abd9-ad8d-f5ba-6c592ad26230@schaufler-ca.com> Date: Wed, 19 Apr 2017 10:55:16 -0700 MIME-Version: 1.0 In-Reply-To: <1492603104.31458.1.camel@tycho.nsa.gov> Content-Type: text/plain; charset=utf-8 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On 4/19/2017 4:58 AM, Stephen Smalley wrote: > 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. > Brilliant. Did the trick. Thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 From: casey@schaufler-ca.com (Casey Schaufler) Date: Wed, 19 Apr 2017 10:55:16 -0700 Subject: SELinux "filtering" capabilities? In-Reply-To: <1492603104.31458.1.camel@tycho.nsa.gov> References: <82d9ff60-6850-0873-1e68-20bd0e27e9ee@schaufler-ca.com> <1492603104.31458.1.camel@tycho.nsa.gov> Message-ID: <62698386-abd9-ad8d-f5ba-6c592ad26230@schaufler-ca.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 4/19/2017 4:58 AM, Stephen Smalley wrote: > 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. > Brilliant. Did the trick. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html