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

Dmitri Pal dpal at redhat.com
Fri Jun 29 14:16:31 UTC 2012


On 06/27/2012 08:53 AM, Rob Crittenden wrote:
> Jan Zelený wrote:
>> Dne úterý 26 června 2012 09:19:34, Rob Crittenden napsal(a):
>>> Jan Zelený wrote:
>>>> Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>>>>> 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.
>>>>
>>>> I'm sorry but I think this is a design decision that should have
>>>> been made
>>>> clear in the design phase. I looked at both documents I was
>>>> building my
>>>> design on to be sure and I can't find any reference to your approach.
>>>> Could you give me any pointer to a place where it has been
>>>> described? Or
>>>> is the specification you just provided complete?
>>>>
>>>> Also this is not some minor change, this might require
>>>> implementation of
>>>> some decision making logic into NSS responder. I'd like to do a triage
>>>> first to figure out when do we want to do this / what priority does
>>>> this
>>>> task have.
>>>>
>>>>
>>>> Thanks
>>>> Jan
>>>
>>> http://freeipa.org/page/SELinux_user_mapping#Evaluation
>>
>> I'm sorry, I completely missed this documentation.
>>
>> I have just one question. When it comes to priority, host specificity
>> is more
>> important than user specificity, right? Let's say I'll have two rules:
>>
>> Rule name: rule1
>> SELinux User: staff_u:s0-s0:c0.c1023
>> Enabled: TRUE
>> Users: tuser1
>> Host category: all
>>
>> Rule name: rule2
>> SELinux User: user_u:s0-s0:c0.c1023
>> Hosts: pinto.greyoak.com
>> Enabled: TRUE
>> User category: all
>>
>> If I understand this correctly, then rule2 should have higher
>> priority and I
>> should be assigned user_u, is that right?
>>
>> Thanks
>> Jan
>>
>
> user_u is correct.

Yes. The logic is based on the specificity.
A more specific rule wins and host part takes precedence over the user part.
>
> rob
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list