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. -- Simo Sorce * Red Hat, Inc * New York -- 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