On 09/01/2016 01:26 PM, Standa Laznicka wrote:
To be explicit: Currently, I go with the new objectClass ipaHBACRuleV2
which differs from ipaHBACRule in removal of obsolete attributes, namely
accessRuleType, sourceHost, sourceHostCategory and accessTime. This new
objectClass makes the rules of the newer type invisible to the older
clients on both FreeIPA and SSSD sides.
On 08/31/2016 12:57 PM, Petr Spacek wrote:
As there were no further objections, the latest changes with the
objectclass implementation that were made according to Honza's
suggestions were pushed to appear in the pull request
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:
I was thinking that for future proofing we could add a version
On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
This sounds like a good idea, but it is not a silver bullet I am
On Fri, 26 Aug 2016, Simo Sorce wrote:
At this point using new object class becomes an attractive
On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
I miss "why" part of "To be able to handle backward
ease, a new object called ipaHBACRulev2 is introduced. " in the
page. If the reason is the above - old client's should
then it has to be mentioned there. Otherwise I don't see a
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
introduce a new object type instead of extending the current.
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
If you make it clear that old clients *DO NOT* respect time
there is no CVE material, it is working as "described".
The admins already have a way to not set those rules for older
by simply grouping newer clients in a different host group and
time rules only there.
So the question really is: should we allow admins to apply an
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
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
make it an easy transition as you just set up the rule and the
will start enforcing the time when it is upgraded but work
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
give admins a good way to apply rules to a specific set of
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
objectlass or something else to similar effect.
Open to discussion.
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
per-host or per-hostgroup by default? Add --force option to
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these
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
(I know 389ds allows us to do an LDAPv3 illegal operation and
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"
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
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
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
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
but otherwise apply the rule to any client.
This should give us the best of all options at once.
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
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
have the new accessRuleType set to "allow_with_time" or should the
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 ->
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
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
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
would mean for what I currently have in
https://github.com/stlaz/sssd/tree/freeipa-trac-547_2. Note that the
patch is really just to get a picture, it currently causes sssd_be
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
rules are not shown to old clients which seems correct as there's no
for admins who might scratch their heads at old clients with no idea
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
detailed specification first.
Given that we have to modify SSSD anyway, I would go for
class with clear definition of "capabilities" (without any obsolete
That should be future proof and without any negative/unforeseen
existing clients + it matches what Jan Pazdziora plans to do for
The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule upon
addition of a time rule to a certain HBAC rule. The process is reversed
when there're no time rules left in that exact HBAC rule. Therefore
rules that may still apply on older clients are visible there, while the
new rules that would not apply are not.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code