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

[Simo Sorce]

On Mon, 2016-08-29 at 08:29 +0200, Jan Cholasta wrote:
> On 26.8.2016 16:39, 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.
> 
> That does not make a lot of sense to me. If the admin does not really 
> care about enforcing the access time, why would they bother setting it 
> in the first place?

It's not that they do not care, but life is not black and white and
sometimes you need to compromise, so you restrict what you can and let
the rest keep working, as client upgrades slide in situation will
improve.


> > 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.
> 
> The second one does not appeal to me, because it is inviting to the kind 
> of mistakes which would allow access when it should not be allowed and 
> IMHO it's better to be safe than sorry.

As a general advice yes, but we need to care about other things, like
usability, and progression.
We did not have time rules at all till now, so allowing smooth upgrades
is important I think.
The nice think about using accessRuleType is that we can set a good
default and then let admins to decide, I like that a lot as it keeps
admins in control and does not force behavior.

Simo.

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