On 31.8.2016 12:42, Standa Laznicka wrote: > On 08/30/2016 03:34 PM, Simo Sorce wrote: >> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote: >>> On 08/26/2016 05:37 PM, Simo Sorce wrote: >>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: >>>>> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote: >>>>>> On Fri, 26 Aug 2016, Simo Sorce wrote: >>>>>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote: >>>>>>>>> I miss "why" part of "To be able to handle backward compatibility >>>>>>>> with >>>>>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the >>>>>>>> design >>>>>>>>> page. If the reason is the above - old client's should ignore time >>>>>>>> rules >>>>>>>>> then it has to be mentioned there. Otherwise I don't see a reason to >>>>>>>>> introduce a new object type instead of extending the current. >>>>>>>> How do you want to enforce HBAC rule that have set time from 10 to 14 >>>>>>>> everyday? With the same objectclass old clients will allow this HBAC >>>>>>>> for >>>>>>>> all day. Isn't this CVE? >>>>>>> This is a discussion worth having. >>>>>>> >>>>>>> In general it is a CVE only if an authorization mechanism fails to work >>>>>>> as advertised. >>>>>>> >>>>>>> If you make it clear that old clients *DO NOT* respect time rules then >>>>>>> there is no CVE material, it is working as "described". >>>>>>> >>>>>>> The admins already have a way to not set those rules for older clients >>>>>>> by simply grouping newer clients in a different host group and applying >>>>>>> time rules only there. >>>>>>> >>>>>>> So the question really is: should we allow admins to apply an HBAC Rule >>>>>>> potentially to older clients that do not understand it and will >>>>>>> therefore allow access at any time of the day, or should we prevent it ? >>>>>>> >>>>>>> This is a hard question to answer and can go both ways. >>>>>>> >>>>>>> A time rule may be something that admins want to enforce at all cost or >>>>>>> deny access. In this case a client that fails to handle it would be a >>>>>>> problem. >>>>>>> >>>>>>> But it may be something that is just used for defense in depth and not a >>>>>>> strictly hard requirement. In this case allowing older clients would >>>>>>> make it an easy transition as you just set up the rule and the client >>>>>>> will start enforcing the time when it is upgraded but work otherwise >>>>>>> with the same rules. >>>>>>> >>>>>>> I am a bit conflicted on trying to decide what scenario we should >>>>>>> target, but the second one appeals to me because host groups do already >>>>>>> give admins a good way to apply rules to a specific set of hosts and >>>>>>> exclude old clients w/o us making it a hard rule. >>>>>>> OTOH if an admin does not understand this difference, they may be >>>>>>> surprised to find out there are clients that do not honor it. >>>>>>> >>>>>>> Perhaps we could find a way to set a flag on the rule such that when set >>>>>>> (and only when set) older clients get excluded by way of changing the >>>>>>> objectlass or something else to similar effect. >>>>>>> >>>>>>> Open to discussion. >>>>>> At this point using new object class becomes an attractive approach. We >>>>>> don't have means to exclude HBAC rules other than applying them >>>>>> per-host/hostgroup. We also have no deny rules. >>>>>> >>>>>> I have another idea: what about enforcing time rules always to apply >>>>>> per-host or per-hostgroup by default? Add --force option to override the >>>>>> behavior but default to not allow --hostcat=all. This would raise >>>>>> awareness and make sure admins are actually applying these rules with >>>>>> intention. >>>>> This sounds like a good idea, but it is not a silver bullet I am afraid. >>>>> >>>>> Simo. >>>> I was thinking that for future proofing we could add a version field, >>>> then reasoned more and realized that changing the object class is >>>> basically the same thing. >>>> >>>> There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass. >>>> (I know 389ds allows us to do an LDAPv3 illegal operation and change it, >>>> but I do not like to depend on that behavoir). >>>> >>>> Now looking into this I had an idea to solve the problem of legacy >>>> clients without having to swap classes. >>>> We can redefine the accessRuleType attribute to be a "capability" type. >>>> >>>> Ie rules that have a timeAccess component will be of type >>>> "allow_with_time" instead of just "allow". >>>> Old clients are supposed to search with accessRuleType=allow (and I can >>>> see that SSSD does that), so an older client will fail to get those >>>> rules as they won't match. >>>> >>>> New clients instead can recognize both types. >>>> >>>> Also if we need a future extension we will simpy add a new access rule >>>> type and we can have the same effect. >>>> The nice thing is that accessRyleType is defined as multivalue (no >>>> SINGLE in schema) so we may actually create compatible rules if we want >>>> to. >>>> Ie we could set both "allow" and "allow_with_time" on an object for >>>> cases where the admin wants to enforce the time part only o newer client >>>> but otherwise apply the rule to any client. >>>> >>>> This should give us the best of all options at once. >>>> >>>> Thoughts ? >>>> >>>> Simo. >>>> >>> Sorry to join the discussion so late, I was away yesterday. >>> >>> I have to say I too like this idea much better than fiddling with the >>> objectClasses. Also, I believe that accessRuleType was originally >>> actually used to distinguish newer version of HBAC rules from the older >>> so we may just do this again and profit from its original purpose. To >>> top it off, this change should be really easy to implement to what I >>> currently have on SSSD side. >>> >>> I was just wondering - would you propose for every newly created rule to >>> have the new accessRuleType set to "allow_with_time" or should the type >>> change with addition of time rules to the HBAC rule as it does >>> currently? Also, should the user be able to modify the type so that a >>> rule with the new type is also visible for older clients (=> he could >>> add "allow" to type anytime)? >> Rules of type allow_with_time will not work on older clients, so we >> should probably default to just the old "allow" schema. >> >> I think in the first implementation the framework/cli/ui should not >> emphasize this attribute but simply replace allow -> allow_with_time if >> a time attribute is added. >> >> In future we may give control of it and allow even to set multiple >> values, after we discuss better if that should be done, and with ample >> warnings to admins. >> >> Also setting a time rule makes a rule incompatible with older clients so >> we should spell it clearly in the CLI/UI with a warning message that >> this rule will not apply at all to older clients. >> >>> Thanks for your ideas, I am very happy with what you suggested here :) >> Thank you. >> >> Simo. >> > So - can we all agree on a solution? > > I took an extra half an hour and created the accessRuleType solution on top of > what I currently have, see patches attached to get the picture what the change > would mean for what I currently have in > https://github.com/stlaz/freeipa/tree/timerules_2 and > https://github.com/stlaz/sssd/tree/freeipa-trac-547_2. Note that the sssd > patch is really just to get a picture, it currently causes sssd_be to core > dump, not sure why and don't want to waste time debugging it right now. > > I myself would in the end rather go for objectClasses implementation as new > rules are not shown to old clients which seems correct as there's no confusion > for admins who might scratch their heads at old clients with no idea why their > HBAC rules don't apply otherwise.
+1, I agree with Standa and Martin Basti. Let me repeat myself: I like the idea of "capabilities" in general but it needs proper design and detailed specification first. Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object class with clear definition of "capabilities" (without any obsolete cruft). That should be future proof and without any negative/unforeseen impact to existing clients + it matches what Jan Pazdziora plans to do for HBAC+URI. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
