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

Jan Zelený jzeleny at redhat.com
Tue Jun 26 06:37:43 UTC 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120626/e10add2e/attachment.sig>


More information about the sssd-devel mailing list