[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Simo Sorce]

On Mon, 2016-08-29 at 11:15 +0200, Jan Pazdziora wrote:
> On Fri, Aug 26, 2016 at 10:39:53AM -0400, Simo Sorce wrote:
> > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
> > > 
> > > 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".
> 
> While that is true, it is worth helping admins to avoid creating
> inadvertent holes in their system. Since the rule needs some
> additional processing on the client, different from the old rules, it
> makes sense to limit exposure to these rules for old clients by
> technical means.
> 
> Note that the URI-based access control of
> 
> 	https://fedorahosted.org/freeipa/ticket/5030
> 	https://www.freeipa.org/page/V4/URI-based_HBAC
> 
> planned/plans to do exactly the same, to avoid wrong processing of new
> rules by old clients.
> 
> Do you see some issue with the new object class being used?
> 
> > 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 ?
> 
> We should allow admins to apply the rule to any client and then
> ensure that the rule does not authorize access where it should not be
> allowed. Yes, access to some (old) clients will be denied even if the
> admin things it should be allowed. We can likely solve that problem by
> a note on the WebUI, about the client version requirements.
> 
> That was we do not need to play games with guessing client's versions
> and have race situations when the admin knows they have upgraded the
> particular client yet IPA not knowing about it yet.
> 
> > 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.
> 
> I prefer the first option. We shouldn't introduce new feature and make
> its behaviour ambiguous from the very start.
> 
> If the access is denied for old clients when the time-based mechanism
> is used, at least it's a motivation to upgrade the clients.

All good arguments except the last one. We are not here to make admins
lices difficult, we are here to make them better. They are often stuck
with older OS version for reasons beyond their control, so we need to
give them options not aut-auts

Simo.


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