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

Simo Sorce simo at redhat.com
Tue Jun 26 11:49:24 UTC 2012


On Tue, 2012-06-26 at 07:23 -0400, Stephen Gallagher wrote:
> 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.

Sorry Steve, but without the correct logic the whole feature is useless.
It is unfortunate the requirements were not communicated properly, but
they are required. The current logic simply doesn't work.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list