[SSSD] [PATCH] SELinux user maps: pick just one map

Rob Crittenden rcritten at redhat.com
Mon Jun 25 21:35:55 UTC 2012


Stephen Gallagher wrote:
> On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>>>> Jan Zelený wrote:
>>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>>>>>> Jan Zelený wrote:
>>>>>>> This patch modifies behavior of SSSD when putting together content of
>>>>>>> user config file for pam_selinux. SSSD will now pick only the first user
>>>>>>> map in the priority list which matches to the user logging in. Other
>>>>>>> maps
>>>>>>> are ignored.
>>>>>>>
>>>>>>> https://fedorahosted.org/sssd/ticket/1360
>>>>>>>
>>>>>>> Rob, please confirm that this is the right and expected behavior.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Jan
>>>>>>
>>>>>> What you have described sounds right. I don't have enough context in
>>>>>> sssd to know whether this patch will achieve that.
>>>>>
>>>>> I realize that. I just wanted to verify that the described behavior is
>>>>> correct. The patch itself will be reviewed by someone else from SSSD team.
>>>>>
>>>>> Thank you for the confirmation
>>>>
>>>> We had a discussion in IRC and it seems that the using of the usermap
>>>> order is incorrect. The list is ordered from least to most permissive
>>>> (xguest ... unconfined).
>>>>
>>>> We want to assign the most permissive context available. So if several
>>>> rules evaluate the same except for context we need to refer to the
>>>> ordered list and pick the most permissive one.
>>>
>>> Following patch selects the right record with respect to ascending order of
>>> permission levels.
>>
>>
>> Ack
>
> Pushed to master.

Maps are still not working properly.

It now always selects the highest priority that a user is associated 
with. This is incorrect. It needs to go through an HBAC-style evaluation 
where the specificity of the user (vs usercat=all) and the host are 
taken into consideration.

So for example these three rules:

   Rule name: test_all
   SELinux User: unconfined_u:s0-s0:c0.c1023
   User category: all
   Host category: all
   Enabled: TRUE

   Rule name: test_tuser1_pinto
   SELinux User: staff_u:s0-s0:c0.c1023
   Enabled: TRUE
   Users: tuser1
   Hosts: pinto.greyoak.com

   Rule name: test_user
   SELinux User: user_u:s0-s0:c0.c1023
   Host category: all
   Enabled: TRUE
   Users: tuser1

If I log into pinto as tuser1 I get assigned unconfined_u. It should be 
staff_u because that rule is more specific than test_all. The only time 
the context ordering should be considered is when there are two rules 
that match with the same specificity.

rob



More information about the sssd-devel mailing list