* SELinux "filtering" capabilities?
@ 2017-04-18 22:37 ` Casey Schaufler
0 siblings, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2017-04-18 22:37 UTC (permalink / raw)
To: LSM, SE Linux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* SELinux "filtering" capabilities?
@ 2017-04-18 22:37 ` Casey Schaufler
0 siblings, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2017-04-18 22:37 UTC (permalink / raw)
To: linux-security-module
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.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux "filtering" capabilities?
2017-04-18 22:37 ` Casey Schaufler
@ 2017-04-19 11:58 ` Stephen Smalley
-1 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2017-04-19 11:58 UTC (permalink / raw)
To: Casey Schaufler, LSM, SE Linux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* SELinux "filtering" capabilities?
@ 2017-04-19 11:58 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2017-04-19 11:58 UTC (permalink / raw)
To: linux-security-module
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.
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux "filtering" capabilities?
2017-04-19 11:58 ` Stephen Smalley
@ 2017-04-19 17:55 ` Casey Schaufler
-1 siblings, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2017-04-19 17:55 UTC (permalink / raw)
To: Stephen Smalley, LSM, SE Linux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* SELinux "filtering" capabilities?
@ 2017-04-19 17:55 ` Casey Schaufler
0 siblings, 0 replies; 6+ messages in thread
From: Casey Schaufler @ 2017-04-19 17:55 UTC (permalink / raw)
To: linux-security-module
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-19 17:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-18 22:37 SELinux "filtering" capabilities? Casey Schaufler
2017-04-18 22:37 ` Casey Schaufler
2017-04-19 11:58 ` Stephen Smalley
2017-04-19 11:58 ` Stephen Smalley
2017-04-19 17:55 ` Casey Schaufler
2017-04-19 17:55 ` Casey Schaufler
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.