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@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/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel