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