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