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