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

[Jan Pazdziora]

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.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat