On Mon, 2011-08-29 at 10:36 -0400, Christopher J. PeBenito wrote:
On 08/29/11 11:10, Miroslav Grepl wrote:
On 08/29/2011 12:52 PM, Christopher J. PeBenito wrote:
On 08/29/11 08:33, Stephen Smalley wrote:
On Fri, 2011-08-26 at 20:51 +0200, Miroslav Grepl wrote:
Together with Dan Walsh, Jan Chadima we made some changes in the openssh package.
But we have the following issue with the following code
...
if (internal-sftp) setuid() getexecon(&scon) setcon(scon) freecon(scon)
...
We have
allow sshd_t unpriv_userdomain:process dyntransition
rule but we get a constraint violation with the following AVC msg
type=AVC msg=audit(1314348650.561:7910): avc: denied { dyntransition } for pid=555 comm="sshd" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0
because of
constrain process dyntransition ( u1 == u2 and r1 == r2 )
My question is why dyntrans is not allowed to change USER or ROLE.
I think just because we haven't previously had a system program using setcon(3) to switch its user/role.
Also because the theory we would be reproducing privilege bracketed domains, so you'd be going to a different privilege in eg httpd_t -> httpd_mycgi_t, and that would not require user or role changes.
Ok, I understand. Thanks.
Could we add an attribute to break this?
Yes, we could add one. The question is if we want the same attribute as the regular transition or a new one. i.e. I'm thinking
constran process dyntranstion ( u1 == u2 or ( t1 == can_change_process_identity and t2 == process_user_target ) );
constran process dyntranstion ( r1 == r2 or ( t1 == can_change_process_identity and t2 == process_user_target ) );
do we want can_change_process_identity attribute or a new one?
If so, then might as well just coalesce into the existing constraint on transition permission.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/29/2011 10:43 AM, Stephen Smalley wrote:
On Mon, 2011-08-29 at 10:36 -0400, Christopher J. PeBenito wrote:
On 08/29/11 11:10, Miroslav Grepl wrote:
On 08/29/2011 12:52 PM, Christopher J. PeBenito wrote:
On 08/29/11 08:33, Stephen Smalley wrote:
On Fri, 2011-08-26 at 20:51 +0200, Miroslav Grepl wrote:
Together with Dan Walsh, Jan Chadima we made some changes in the openssh package.
But we have the following issue with the following code
...
if (internal-sftp) setuid() getexecon(&scon) setcon(scon) freecon(scon)
...
We have
allow sshd_t unpriv_userdomain:process dyntransition
rule but we get a constraint violation with the following AVC msg
type=AVC msg=audit(1314348650.561:7910): avc: denied { dyntransition } for pid=555 comm="sshd" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0
because of
constrain process dyntransition ( u1 == u2 and r1 == r2 )
My question is why dyntrans is not allowed to change USER or ROLE.
I think just because we haven't previously had a system program using setcon(3) to switch its user/role.
Also because the theory we would be reproducing privilege bracketed domains, so you'd be going to a different privilege in eg httpd_t -> httpd_mycgi_t, and that would not require user or role changes.
Ok, I understand. Thanks.
Could we add an attribute to break this?
Yes, we could add one. The question is if we want the same attribute as the regular transition or a new one. i.e. I'm thinking
constran process dyntranstion ( u1 == u2 or ( t1 == can_change_process_identity and t2 == process_user_target ) );
constran process dyntranstion ( r1 == r2 or ( t1 == can_change_process_identity and t2 == process_user_target ) );
do we want can_change_process_identity attribute or a new one?
If so, then might as well just coalesce into the existing constraint on transition permission.
Ok I like Stephen's better.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Stephen Smalley