[SSSD] Re: What's the best way to debug SELinux issues on SSSD?

2018-05-22 Thread Jakub Hrozek 


> On 21 May 2018, at 23:58, Fabiano Fidêncio  wrote:
> 
> On Mon, May 21, 2018 at 10:32 PM, Jakub Hrozek  wrote:
>> 
>> 
>>> On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
>>> 
>>> People,
>>> 
>>> I've been trying to debug a SELinux issue related to the domain
>>> resolution order.
>>> 
>>> Basically, if there's no domain_reoslution_order set:
>>> [root@client1 vagrant]# ssh -l admin localhost
>>> Password:
>>> Last login: Mon May 21 19:00:06 2018 from ::1
>>> [admin@client1 ~]$ id -Z
>>> staff_u:staff_r:staff_t:s0-s0:c0.c1023
>>> 
>>> But, if domain_resolution_order is set:
>>> [root@client1 vagrant]# ssh -l admin localhost
>>> Password:
>>> Last login: Mon May 21 19:30:45 2018 from ::1
>>> [admin@ipa.example@client1 ~]$ id -Z
>>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> 
>> Since sssd calls into libsemanage, then I would start with looking at the 
>> output of “semanage login -l”.
> 
> You gave me this tip before, I did test it but I forgot to add details
> about it :-/
> 
> The output is basically the same with or without domain_resolution_order set:
> 
> [root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
> domain_resolution_order = foo
> [root@client1 x86_64]# systemctl restart sssd
> [root@client1 x86_64]# semanage login -l
> 
> Login Name   SELinux User MLS/MCS RangeService
> 
> __default__  unconfined_u s0-s0:c0.c1023   *
> adminstaff_u  s0-s0:c0.c1023   *
> root unconfined_u s0-s0:c0.c1023   *
> 
> 
> [root@client1 x86_64]# vim /etc/sssd/sssd.conf
> [root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
> #domain_resolution_order = foo
> [root@client1 x86_64]# systemctl restart sssd
> [root@client1 x86_64]# semanage login -l
> 
> Login Name   SELinux User MLS/MCS RangeService
> 
> __default__  unconfined_u s0-s0:c0.c1023   *
> adminstaff_u  s0-s0:c0.c1023   *
> root unconfined_u s0-s0:c0.c1023   *
> 
> 
>> Is the context after selinux_child runs to completion set for admin or 
>> admin@ipa.example?
> 
> In the selinux_child.log I can only see:
> [[sssd[selinux_child[18149 [unpack_buffer] (0x2000): username: admin

Right and looking at the selinux_child code, we /try/ to format the name to the 
output format that getpwnam would return for precisely this reason (see 
selinux_child_setup). but because we don’t know about the extra qualification 
that the domain suffix causes, we fail to qualify the name.

And looking at the pam_selinux code, it does canonicalize the username with 
getpwnam:

496   if (!(username = get_item(pamh, PAM_USER))) {
497 pam_syslog(pamh, LOG_ERR, "Cannot obtain the user name");
498 return PAM_USER_UNKNOWN;
499   }
500
501   if ((pwd = pam_modutil_getpwnam(pamh, username)) != NULL) {
502 username = pwd->pw_name;
503   } /* ignore error and keep using original username */
504

So selinux_child sets the context to admin, but pam_selinux checks the context 
of admin@domain because that’s what getpwnam(“admin”) returns.

> 
> And it happens for both cases, with or without domain_resolution_order
> being used.
> 
>> Maybe libsemanage canonicalizes the name or UID with getpnam/uid and 
>> therefore uses the qualified name but because the provider has no sense of 
>> the domain_resolution_order, it calls sss_set_seuser() with the shortname?
> 
> That's a good question. sss_set_seuser() hasn't been called, at all.

There is an optimization that first queries the semanage back end and if the 
context is already set, then sss_set_seuser() is just skipped. Setting the 
context is not/was not a cheap operation.

> 
>> 
>> Looking at whether we call sss_set_seuser() with the correct parameters 
>> might give some hint as well.
>> 
>>> 
>>> First thing that came to my mind was to take a look at
>>> selinux_child.logs, but it didn't give me any clue as the logs are
>>> exactly the same for both cases:
>>> 
>>> No domain_resolution_order set:
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>>> (0x0400): selinux_child started.
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>>> (0x2000): Running with effective IDs: [0][0].
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>>> (0x2000): Running with real IDs [0][0].
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>>> (0x0400): context initialized
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>>> [unpack_buffer] (0x2000): seuser length: 7
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>>> [unpack_buffer] (0x2000): seuser: staff_u
>>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>>> [unpack_buffer] (0x2000): mls_range length: 14
>>> (Mon May 21 19:30:44 2018)

[SSSD] Re: What's the best way to debug SELinux issues on SSSD?

2018-05-21 Thread Fabiano Fidêncio 
On Mon, May 21, 2018 at 10:32 PM, Jakub Hrozek  wrote:
>
>
>> On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
>>
>> People,
>>
>> I've been trying to debug a SELinux issue related to the domain
>> resolution order.
>>
>> Basically, if there's no domain_reoslution_order set:
>> [root@client1 vagrant]# ssh -l admin localhost
>> Password:
>> Last login: Mon May 21 19:00:06 2018 from ::1
>> [admin@client1 ~]$ id -Z
>> staff_u:staff_r:staff_t:s0-s0:c0.c1023
>>
>> But, if domain_resolution_order is set:
>> [root@client1 vagrant]# ssh -l admin localhost
>> Password:
>> Last login: Mon May 21 19:30:45 2018 from ::1
>> [admin@ipa.example@client1 ~]$ id -Z
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> Since sssd calls into libsemanage, then I would start with looking at the 
> output of “semanage login -l”.

You gave me this tip before, I did test it but I forgot to add details
about it :-/

The output is basically the same with or without domain_resolution_order set:

[root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
domain_resolution_order = foo
[root@client1 x86_64]# systemctl restart sssd
[root@client1 x86_64]# semanage login -l

Login Name   SELinux User MLS/MCS RangeService

__default__  unconfined_u s0-s0:c0.c1023   *
adminstaff_u  s0-s0:c0.c1023   *
root unconfined_u s0-s0:c0.c1023   *


[root@client1 x86_64]# vim /etc/sssd/sssd.conf
[root@client1 x86_64]# cat /etc/sssd/sssd.conf | grep domain_resolution_order
#domain_resolution_order = foo
[root@client1 x86_64]# systemctl restart sssd
[root@client1 x86_64]# semanage login -l

Login Name   SELinux User MLS/MCS RangeService

__default__  unconfined_u s0-s0:c0.c1023   *
adminstaff_u  s0-s0:c0.c1023   *
root unconfined_u s0-s0:c0.c1023   *


> Is the context after selinux_child runs to completion set for admin or 
> admin@ipa.example?

In the selinux_child.log I can only see:
[[sssd[selinux_child[18149 [unpack_buffer] (0x2000): username: admin

And it happens for both cases, with or without domain_resolution_order
being used.

> Maybe libsemanage canonicalizes the name or UID with getpnam/uid and 
> therefore uses the qualified name but because the provider has no sense of 
> the domain_resolution_order, it calls sss_set_seuser() with the shortname?

That's a good question. sss_set_seuser() hasn't been called, at all.

>
> Looking at whether we call sss_set_seuser() with the correct parameters might 
> give some hint as well.
>
>>
>> First thing that came to my mind was to take a look at
>> selinux_child.logs, but it didn't give me any clue as the logs are
>> exactly the same for both cases:
>>
>> No domain_resolution_order set:
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x0400): selinux_child started.
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x2000): Running with effective IDs: [0][0].
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x2000): Running with real IDs [0][0].
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x0400): context initialized
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): seuser length: 7
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): seuser: staff_u
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): mls_range length: 14
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): username length: 5
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [unpack_buffer] (0x2000): username: admin
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x0400): performing selinux operations
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
>> staff_u mls: s0-s0:c0.c1023
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [pack_buffer] (0x0400): result [0]
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
>> [prepare_response] (0x4000): r->size: 4
>> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
>> (0x0400): selinux_child completed successfully
>>
>> domain_resolution_order set:
>> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
>> (0x0400): selinux_child started.
>> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
>> (0x2000): Running with effective IDs: [0][0].
>> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
>> (0x2000): Running with real IDs [0][0].
>> (Mon May 21 19:31:36 2018)

[SSSD] Re: What's the best way to debug SELinux issues on SSSD?

2018-05-21 Thread Jakub Hrozek 


> On 21 May 2018, at 21:39, Fabiano Fidêncio  wrote:
> 
> People,
> 
> I've been trying to debug a SELinux issue related to the domain
> resolution order.
> 
> Basically, if there's no domain_reoslution_order set:
> [root@client1 vagrant]# ssh -l admin localhost
> Password:
> Last login: Mon May 21 19:00:06 2018 from ::1
> [admin@client1 ~]$ id -Z
> staff_u:staff_r:staff_t:s0-s0:c0.c1023
> 
> But, if domain_resolution_order is set:
> [root@client1 vagrant]# ssh -l admin localhost
> Password:
> Last login: Mon May 21 19:30:45 2018 from ::1
> [admin@ipa.example@client1 ~]$ id -Z
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Since sssd calls into libsemanage, then I would start with looking at the 
output of “semanage login -l”. Is the context after selinux_child runs to 
completion set for admin or admin@ipa.example? Maybe libsemanage canonicalizes 
the name or UID with getpnam/uid and therefore uses the qualified name but 
because the provider has no sense of the domain_resolution_order, it calls 
sss_set_seuser() with the shortname?

Looking at whether we call sss_set_seuser() with the correct parameters might 
give some hint as well.

> 
> First thing that came to my mind was to take a look at
> selinux_child.logs, but it didn't give me any clue as the logs are
> exactly the same for both cases:
> 
> No domain_resolution_order set:
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x0400): selinux_child started.
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x2000): Running with effective IDs: [0][0].
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x2000): Running with real IDs [0][0].
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x0400): context initialized
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): seuser length: 7
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): seuser: staff_u
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): mls_range length: 14
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): username length: 5
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [unpack_buffer] (0x2000): username: admin
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x0400): performing selinux operations
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> staff_u mls: s0-s0:c0.c1023
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [pack_buffer] (0x0400): result [0]
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351
> [prepare_response] (0x4000): r->size: 4
> (Mon May 21 19:30:44 2018) [[sssd[selinux_child[23351 [main]
> (0x0400): selinux_child completed successfully
> 
> domain_resolution_order set:
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x0400): selinux_child started.
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x2000): Running with effective IDs: [0][0].
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x2000): Running with real IDs [0][0].
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x0400): context initialized
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): seuser length: 7
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): seuser: staff_u
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): mls_range length: 14
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): username length: 5
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [unpack_buffer] (0x2000): username: admin
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x0400): performing selinux operations
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [seuser_needs_update] (0x2000): getseuserbyname: ret: 0 seuser:
> staff_u mls: s0-s0:c0.c1023
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [pack_buffer] (0x0400): result [0]
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398
> [prepare_response] (0x4000): r->size: 4
> (Mon May 21 19:31:36 2018) [[sssd[selinux_child[23398 [main]
> (0x0400): selinux_child completed successfully
> 
> Taking a look at the IPA provider, logs also do like the very same:
> https://paste.fedoraproject.org/paste/FKhvxyj3clzXuE5C7tMGhw (pastebin
> is huge!)
> 
> Some tip on which logs I could take a look and/or part of the code I
> could instrument in order to, at least, get