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

Stephen Gallagher sgallagh at redhat.com
Tue Jun 26 11:23:29 UTC 2012


On Tue, 2012-06-26 at 08:37 +0200, 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.

I agree with Jan here. Our original design instructions were to find a
match, and if more than one matches, use the priority to break the tie.
Specificity is a *very* difficult concept to implement, especially where
groups are involved. (e.g. suppose the SELinux rule is users in groupA
get one role assigned, users in groupB get a different role assigned,
but groupB is a nested group below groupA).

This is a brand-new feature that should have a separate RFE filed. We
need a new, complete design documentation describing the methods for
determining specificity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120626/b27febe8/attachment.sig>


More information about the sssd-devel mailing list