Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/09/2016 02:58 PM, Simo Sorce wrote: On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote: On 09/03/2016 06:25 PM, Jan Pazdziora wrote: On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote: The thing is we (and admins) will be stuck with old client s for a loong time, so we need to make it clear to them what works for what. We need to allow admins to create rules that work for both new and old client w/o interfering with each other. In your scheme there must be a way to create a set of rule such that old clients can login at any time while newer clients use time rules. that was easy to accomplish by adding an auxiliary class and simply defining a new type. Old clients would see old stuff only, new clients would add time rules if present. If we have 2 completely different objects because the admin has to create both, then old clients still care only for the old rule, new clients instead have an interesting challenge, what rule do they apply ? You use host groups to serve the old rule to old clients and time-based rule to new clients. Each client will apply the rule they see. If you happen to serve the old rule to the new client, access will be allowed no matter what the other, time-based rule says. You do not use magic to interpret one rule differently, one way on one version of client and other way on different client version. How do you make sure a new client will enforce time restriction when it looks up the old rule as well ? You make sure the new client does not see the old rule. Of course admins can always create very barrow host groups and apply rules only to them, but this is burdensome if you have a *lot* of clients and some other people are tasked to slowly upgrade them. It is possible though, so having 2 separate objects that new clients know about is potentially ok. I would prefer a scheme where they could be combined though for maximum flexibility with as little as possible ambiguity. I agree that managing separate host group membership might be and extra work. But it seems to be the only way to remove the ambiguity. I also believe there's no way avoiding that (if we want to be somehow backward compatible). I would just love us to come to a consensus as I am growing weary of this discussion and am willing to go with just anything as long as it's somehow OK with most people. Could we therefore decide to go with something, please? As long as the tooling does not try to replace object classes I am ok with the solution most people agree on. Simo. So, basically, we are back at accessRuleType usage, which I guess is kind of ok? We may either use its multi-valueness (is that a word?) or be setting it as flags (e.g. "tu" or "ut" for URI with time rules etc.). In the multi-valued case, when someone adds "allow" amongst the values, it will screw HBAC evaluation up (=> deny even if it's among allow rules for the given host) but I guess that's something we could live with. In the flag-case, the filters for obtaining the rules from IPA may seem rather ridiculous (substring match) and may be a very bad decision for future development. Also, anyone is able to add "allow" as another value but that would just be their fault. In both cases, "allow" as an only value may be the default which states the rule may be evaluated even on older clients and SSSD just has to guess what the rule is capable of (which is OK with time rules as if there's none it means "always allow" should previous evaluation allow as well). Please note that I rather included the rather "naive" flag implementation just to make sure to cover everything. We could just as well of course add something like "capabilities" attribute to ipaHBACRule object as another solution but that's starting to be an overkill IMO. Standa -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote: > On 09/03/2016 06:25 PM, Jan Pazdziora wrote: > > On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote: > >> The thing is we (and admins) will be stuck with old client s for a loong > >> time, so we need to make it clear to them what works for what. We need > >> to allow admins to create rules that work for both new and old client > >> w/o interfering with each other. > >> In your scheme there must be a way to create a set of rule such that old > >> clients can login at any time while newer clients use time rules. > >> that was easy to accomplish by adding an auxiliary class and simply > >> defining a new type. > >> Old clients would see old stuff only, new clients would add time rules > >> if present. > >> If we have 2 completely different objects because the admin has to > >> create both, then old clients still care only for the old rule, new > >> clients instead have an interesting challenge, what rule do they apply ? > > You use host groups to serve the old rule to old clients and time-based > > rule to new clients. Each client will apply the rule they see. > > > > If you happen to serve the old rule to the new client, access will > > be allowed no matter what the other, time-based rule says. > > > > You do not use magic to interpret one rule differently, one way on > > one version of client and other way on different client version. > > > >> How do you make sure a new client will enforce time restriction when it > >> looks up the old rule as well ? > > You make sure the new client does not see the old rule. > > > >> Of course admins can always create very barrow host groups and apply > >> rules only to them, but this is burdensome if you have a *lot* of > >> clients and some other people are tasked to slowly upgrade them. It is > >> possible though, so having 2 separate objects that new clients know > >> about is potentially ok. I would prefer a scheme where they could be > >> combined though for maximum flexibility with as little as possible > >> ambiguity. > > I agree that managing separate host group membership might be > > and extra work. But it seems to be the only way to remove the ambiguity. > > > I also believe there's no way avoiding that (if we want to be somehow > backward compatible). > > I would just love us to come to a consensus as I am growing weary of > this discussion and am willing to go with just anything as long as it's > somehow OK with most people. Could we therefore decide to go with > something, please? As long as the tooling does not try to replace object classes I am ok with the solution most people agree on. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/03/2016 06:25 PM, Jan Pazdziora wrote: On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote: The thing is we (and admins) will be stuck with old client s for a loong time, so we need to make it clear to them what works for what. We need to allow admins to create rules that work for both new and old client w/o interfering with each other. In your scheme there must be a way to create a set of rule such that old clients can login at any time while newer clients use time rules. that was easy to accomplish by adding an auxiliary class and simply defining a new type. Old clients would see old stuff only, new clients would add time rules if present. If we have 2 completely different objects because the admin has to create both, then old clients still care only for the old rule, new clients instead have an interesting challenge, what rule do they apply ? You use host groups to serve the old rule to old clients and time-based rule to new clients. Each client will apply the rule they see. If you happen to serve the old rule to the new client, access will be allowed no matter what the other, time-based rule says. You do not use magic to interpret one rule differently, one way on one version of client and other way on different client version. How do you make sure a new client will enforce time restriction when it looks up the old rule as well ? You make sure the new client does not see the old rule. Of course admins can always create very barrow host groups and apply rules only to them, but this is burdensome if you have a *lot* of clients and some other people are tasked to slowly upgrade them. It is possible though, so having 2 separate objects that new clients know about is potentially ok. I would prefer a scheme where they could be combined though for maximum flexibility with as little as possible ambiguity. I agree that managing separate host group membership might be and extra work. But it seems to be the only way to remove the ambiguity. I also believe there's no way avoiding that (if we want to be somehow backward compatible). I would just love us to come to a consensus as I am growing weary of this discussion and am willing to go with just anything as long as it's somehow OK with most people. Could we therefore decide to go with something, please? -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote: > > The thing is we (and admins) will be stuck with old client s for a loong > time, so we need to make it clear to them what works for what. We need > to allow admins to create rules that work for both new and old client > w/o interfering with each other. > In your scheme there must be a way to create a set of rule such that old > clients can login at any time while newer clients use time rules. > that was easy to accomplish by adding an auxiliary class and simply > defining a new type. > Old clients would see old stuff only, new clients would add time rules > if present. > If we have 2 completely different objects because the admin has to > create both, then old clients still care only for the old rule, new > clients instead have an interesting challenge, what rule do they apply ? You use host groups to serve the old rule to old clients and time-based rule to new clients. Each client will apply the rule they see. If you happen to serve the old rule to the new client, access will be allowed no matter what the other, time-based rule says. You do not use magic to interpret one rule differently, one way on one version of client and other way on different client version. > How do you make sure a new client will enforce time restriction when it > looks up the old rule as well ? You make sure the new client does not see the old rule. > Of course admins can always create very barrow host groups and apply > rules only to them, but this is burdensome if you have a *lot* of > clients and some other people are tasked to slowly upgrade them. It is > possible though, so having 2 separate objects that new clients know > about is potentially ok. I would prefer a scheme where they could be > combined though for maximum flexibility with as little as possible > ambiguity. I agree that managing separate host group membership might be and extra work. But it seems to be the only way to remove the ambiguity. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Thu, 2016-09-01 at 17:48 +0200, Standa Laznicka wrote: > If an admin wants the capabilities of time rules then they should just > upgrade the clients. If that is a problem, it's their choice. They can > either create a special host group for those clients that just won't > upgrade or just revoke access to them if it's a problem of a stubborn > user who does not want their system upgraded. This is a very naive view of the problem. first of all what admins want and what admins can have *and when* are 2 completely different things. Admins may *prefer* to enforce time rules but it may not be a deal breaker if some clients do not follow them. They may be ok to have a period of time i which this is not a hard rule. Say they are in the process of migrating 3000 clients from RHEL5.11 to RHEL7.4, they know the roll out will take 6 months, they want a time rule established so that in 6 months all clients will allow access only from 8AM CET to 6PM CET, but they are ok to allow access at all times until a client is migrated. Of course they may simply wait and change rules after all clients are migrated, but maybe their goal in setting rules immediately is that they can test them to see if their users are negatively impacted immediately so they deal with issues as they come slowly as one client after the other is migrated instead of having it all at once on "judgment" day. This is just an example scenario but I find it totally reasonable. Are there other ways to go about it ? Yes, definitely, as mentioned host groups can be used to control which clients see what. I am just saying this is not a black and white problem, there are various shades of gray. > Having a single object would also be wrong - there's no way telling > the older clients to ignore the objects you want them to ignore if you > want them not to ignore some. Yes there is, hostgroups again, you see, it works both ways :-) > But all and all thank you for the explanation with the example, it > made some of your previous points more clear. Sure. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/01/2016 05:18 PM, Simo Sorce wrote: On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote: On 09/01/2016 03:06 PM, Simo Sorce wrote: On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote: The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule upon addition of a time rule to a certain HBAC rule. Honestly I am against this. If you really want the two objects to be incompatible then you tell the admin he can't add time rules to old objects. The new object type should clearly identified as a new rule type and the admin will have to create a new rule of the correct type and remove/disable or retain the old rule as he prefers. I do not think we should ever try to switch objectclasses dynamically. Simo. A child's question: why not? Also, should it come to life like you propose, what would you expect the user interface to be like? LDAPv3 does not allow changing structural classes, 389ds allows it but it is a non-standard feature. I do not want to create issues to people that create solutions that do things like synchronizing our LDAP tree to another LDAP server, for caching, proxying or anything else. It is one thing to allow to do something illegal in the LDAP protocol, it is *entirely* different to rely on an illegal feature in day to day operations. Furthermore when you change a rule this way old clients will suddenly see a rule disappear as it will not match their queries anymore. If you silently do this change in the framework an admin may not realize this is the case and break access to his legacy clients. If the admin has to delete and recreate a rule instead it will be much clear to the admin that this is the case. So the above is for why I am pretty against switching objectclass. Please do not do that, it is a NACK from me. Thank you for the explanation, I was actually really curious about this as I still don't have that much experience and I just don't get some implications. But below find additional things I have been thinking: The thing is we (and admins) will be stuck with old client s for a loong time, so we need to make it clear to them what works for what. We need to allow admins to create rules that work for both new and old client w/o interfering with each other. In your scheme there must be a way to create a set of rule such that old clients can login at any time while newer clients use time rules. that was easy to accomplish by adding an auxiliary class and simply defining a new type. Old clients would see old stuff only, new clients would add time rules if present. If we have 2 completely different objects because the admin has to create both, then old clients still care only for the old rule, new clients instead have an interesting challenge, what rule do they apply ? How do you make sure a new client will enforce time restriction when it looks up the old rule as well ? After all the old rule grants access at "all times". Of course admins can always create very barrow host groups and apply rules only to them, but this is burdensome if you have a *lot* of clients and some other people are tasked to slowly upgrade them. It is possible though, so having 2 separate objects that new clients know about is potentially ok. I would prefer a scheme where they could be combined though for maximum flexibility with as little as possible ambiguity. If an admin wants the capabilities of time rules then they should just upgrade the clients. If that is a problem, it's their choice. They can either create a special host group for those clients that just won't upgrade or just revoke access to them if it's a problem of a stubborn user who does not want their system upgraded. Having a single object would also be wrong - there's no way telling the older clients to ignore the objects you want them to ignore if you want them not to ignore some. But all and all thank you for the explanation with the example, it made some of your previous points more clear. -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote: > On 09/01/2016 03:06 PM, Simo Sorce wrote: > > On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote: > >> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule > >> upon > >> addition of a time rule to a certain HBAC rule. > > Honestly I am against this. > > > > If you really want the two objects to be incompatible then you tell the > > admin he can't add time rules to old objects. > > The new object type should clearly identified as a new rule type and the > > admin will have to create a new rule of the correct type and > > remove/disable or retain the old rule as he prefers. > > > > I do not think we should ever try to switch objectclasses dynamically. > > > > Simo. > > > A child's question: why not? > > Also, should it come to life like you propose, what would you expect the > user interface to be like? LDAPv3 does not allow changing structural classes, 389ds allows it but it is a non-standard feature. I do not want to create issues to people that create solutions that do things like synchronizing our LDAP tree to another LDAP server, for caching, proxying or anything else. It is one thing to allow to do something illegal in the LDAP protocol, it is *entirely* different to rely on an illegal feature in day to day operations. Furthermore when you change a rule this way old clients will suddenly see a rule disappear as it will not match their queries anymore. If you silently do this change in the framework an admin may not realize this is the case and break access to his legacy clients. If the admin has to delete and recreate a rule instead it will be much clear to the admin that this is the case. So the above is for why I am pretty against switching objectclass. Please do not do that, it is a NACK from me. But below find additional things I have been thinking: The thing is we (and admins) will be stuck with old client s for a loong time, so we need to make it clear to them what works for what. We need to allow admins to create rules that work for both new and old client w/o interfering with each other. In your scheme there must be a way to create a set of rule such that old clients can login at any time while newer clients use time rules. that was easy to accomplish by adding an auxiliary class and simply defining a new type. Old clients would see old stuff only, new clients would add time rules if present. If we have 2 completely different objects because the admin has to create both, then old clients still care only for the old rule, new clients instead have an interesting challenge, what rule do they apply ? How do you make sure a new client will enforce time restriction when it looks up the old rule as well ? After all the old rule grants access at "all times". Of course admins can always create very barrow host groups and apply rules only to them, but this is burdensome if you have a *lot* of clients and some other people are tasked to slowly upgrade them. It is possible though, so having 2 separate objects that new clients know about is potentially ok. I would prefer a scheme where they could be combined though for maximum flexibility with as little as possible ambiguity. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/01/2016 03:06 PM, Simo Sorce wrote: On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote: The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule upon addition of a time rule to a certain HBAC rule. Honestly I am against this. If you really want the two objects to be incompatible then you tell the admin he can't add time rules to old objects. The new object type should clearly identified as a new rule type and the admin will have to create a new rule of the correct type and remove/disable or retain the old rule as he prefers. I do not think we should ever try to switch objectclasses dynamically. Simo. A child's question: why not? Also, should it come to life like you propose, what would you expect the user interface to be like? -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/01/2016 02:14 PM, Petr Spacek wrote: On 1.9.2016 14:09, Standa Laznicka wrote: On 09/01/2016 01:26 PM, Standa Laznicka wrote: On 08/31/2016 12:57 PM, Petr Spacek wrote: 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote: > The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule > upon > addition of a time rule to a certain HBAC rule. Honestly I am against this. If you really want the two objects to be incompatible then you tell the admin he can't add time rules to old objects. The new object type should clearly identified as a new rule type and the admin will have to create a new rule of the correct type and remove/disable or retain the old rule as he prefers. I do not think we should ever try to switch objectclasses dynamically. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 1.9.2016 14:09, Standa Laznicka wrote: > On 09/01/2016 01:26 PM, Standa Laznicka wrote: >> On 08/31/2016 12:57 PM, Petr Spacek wrote: >>> 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: 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. >>> I was thinking that for future proofing we could add a version field, >>> 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 objectclass. >>> (I know 389ds allows us to do an LDAPv3 illegal operation and change it, >>> 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" type. >>> >>> Ie rules that have a timeAccess component will be of type >>> "allow_with_time" instead of
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 09/01/2016 01:26 PM, Standa Laznicka wrote: On 08/31/2016 12:57 PM, Petr Spacek wrote: 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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 older so
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/31/2016 12:57 PM, Petr Spacek wrote: 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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 older so we may just do this again and profit from its original purpose. To top it off, this change should
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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: > 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. Ie we could set both "allow" and
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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 older 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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: > >> 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. > > I was thinking that for future proofing we could add a version field, > > 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 objectclass. > > (I know 389ds allows us to do an LDAPv3 illegal operation and change it, > > 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" type. > > > > 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 I can > > 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 rule > > 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 we want > > to. > > 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 client > > but otherwise apply the rule to any client. > > > > This should give
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 30.08.2016 11:51, Standa Laznicka wrote: On 08/30/2016 09:34 AM, Standa Laznicka wrote: On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: On Tue, 30 Aug 2016, Jan Cholasta wrote: On 30.8.2016 08:47, 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/30/2016 09:34 AM, Standa Laznicka wrote: On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: On Tue, 30 Aug 2016, Jan Cholasta wrote: On 30.8.2016 08:47, 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with attributeRuleType. I do realize that (even though I
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/30/2016 09:23 AM, Alexander Bokovoy wrote: On Tue, 30 Aug 2016, Jan Cholasta wrote: On 30.8.2016 08:47, 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with attributeRuleType. I do realize that (even though I touched this in my first question) but this solution
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Tue, 30 Aug 2016, Jan Cholasta wrote: On 30.8.2016 08:47, 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with attributeRuleType. Also, I believe that accessRuleType was originally actually used to distinguish newer version of HBAC rules from the older so we may just do this again and profit from
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 30.8.2016 08:47, 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: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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. Note that the resulting code will be exactly the same except for the attribute name - you won't be fiddling with objectClass but with attributeRuleType. Also, I believe that accessRuleType was originally actually used to distinguish newer version of HBAC rules from the older so we may just do this again and profit from its original purpose. The original
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 05:37 PM, Simo Sorce wrote: On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? Simo. 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 older 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 rule to have the new accessRuleType set to
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Mon, 2016-08-29 at 16:35 +0200, Petr Spacek wrote: > On 29.8.2016 16:34, Simo Sorce wrote: > > On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: > >> On 26.8.2016 17:40, Simo Sorce wrote: > >>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > 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 > client > but otherwise apply the rule to any client. > >>> > >>> I notice that SSSD does not like it if there are multiple values on this > >>> attribute, but we could change this easily in older clients when we > >>> update them. worst case the rule will not apply and admins have to > >>> create 2 rules, one with allow and one with allow_with_time. > >> > >> I like the idea in general but it needs proper design and detailed > >> specification first. > >> > >> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 > >> object > >> class with clear definition of "capabilities" (without any obsolete cruft). > >> > >> That should be future proof and without any negative impact to existing > >> clients. > > > > ipaHBACRule2 is needed anyway, it is just how it is implemented that > > differs, I really think we should go the accessRuleType route, I find it > > superior to messing with objects by ripping off structural objectclasses > > and replacing them. > > So we are in agreement ;-) If you liked my proposal then I guess we are, it wasn't clear to me :-) 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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 -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 29.8.2016 16:34, Simo Sorce wrote: > On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: >> On 26.8.2016 17:40, Simo Sorce wrote: >>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: 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 client but otherwise apply the rule to any client. >>> >>> I notice that SSSD does not like it if there are multiple values on this >>> attribute, but we could change this easily in older clients when we >>> update them. worst case the rule will not apply and admins have to >>> create 2 rules, one with allow and one with allow_with_time. >> >> I like the idea in general but it needs proper design and detailed >> specification first. >> >> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object >> class with clear definition of "capabilities" (without any obsolete cruft). >> >> That should be future proof and without any negative impact to existing >> clients. > > ipaHBACRule2 is needed anyway, it is just how it is implemented that > differs, I really think we should go the accessRuleType route, I find it > superior to messing with objects by ripping off structural objectclasses > and replacing them. So we are in agreement ;-) -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote: > On 26.8.2016 17:40, Simo Sorce wrote: > > On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > >> 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 > >> client > >> but otherwise apply the rule to any client. > > > > I notice that SSSD does not like it if there are multiple values on this > > attribute, but we could change this easily in older clients when we > > update them. worst case the rule will not apply and admins have to > > create 2 rules, one with allow and one with allow_with_time. > > I like the idea in general but it needs proper design and detailed > specification first. > > Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object > class with clear definition of "capabilities" (without any obsolete cruft). > > That should be future proof and without any negative impact to existing > clients. ipaHBACRule2 is needed anyway, it is just how it is implemented that differs, I really think we should go the accessRuleType route, I find it superior to messing with objects by ripping off structural objectclasses and replacing them. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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 -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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 -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.8.2016 17:40, Simo Sorce wrote: > On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: >> 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 >> client >> but otherwise apply the rule to any client. > > I notice that SSSD does not like it if there are multiple values on this > attribute, but we could change this easily in older clients when we > update them. worst case the rule will not apply and admins have to > create 2 rules, one with allow and one with allow_with_time. I like the idea in general but it needs proper design and detailed specification first. Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object class with clear definition of "capabilities" (without any obsolete cruft). That should be future proof and without any negative impact to existing clients. -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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? 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. 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. Simo. -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote: > 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 > client > but otherwise apply the rule to any client. I notice that SSSD does not like it if there are multiple values on this attribute, but we could change this easily in older clients when we update them. worst case the rule will not apply and admins have to create 2 rules, one with allow and one with allow_with_time. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote: > 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. I was thinking that for future proofing we could add a version field, 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 objectclass. (I know 389ds allows us to do an LDAPv3 illegal operation and change it, 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" type. 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 I can 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 rule 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 we want to. 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 client but otherwise apply the rule to any client. This should give us the best of all options at once. Thoughts ? 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
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. 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Fri, 2016-08-26 at 11:55 +0200, Martin Basti wrote:
>
> On 26.08.2016 11:43, Jan Cholasta wrote:
> > Hi,
> >
> > On 11.8.2016 12:34, Stanislav Laznicka wrote:
> >> Hello,
> >>
> >> I updated the design of the Time-Based HBAC Policies according to the
> >> discussion we led here earlier. Please check the design page
> >> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
> >> changes are in the Implementation and Feature Management sections. I
> >> also added a short How to Use section.
> >
> > 1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
> > ipaMemberTimeRule
> >
> >
> > 2) Source hosts are deprecated and thus should be removed from
> > ipaHBACRuleV2.
> >
> >
> > 3) Since time rules are defined by memberTimeRule, accessTime should
> > be removed from ipaHBACRuleV2.
>
> ad 2) 3)
>
> Because backward compatibility, ipaHBACRuleV2 must contain all
> attributes from ipaHBACRule as MAY
>
> With current approach, when timerule is added to HBAC, we just change
> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
> attributes that was defined in older HBAC. Removing any attrs from
> ipaHBACRuleV2 can cause schema violation.
Is there a good reason to "change" the objectclass instead of just
"adding" to it ?
Are v1 and v2 "incompatible" at the object lvl ?
(Sorry I probably knew the answer last I looked at it but I somehow
forgot).
> I'm not sure if want to handle this in code (removing deprecated
> attributes from HBAC entry when timerule is added)
>
> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to
> add it back.
What is it set to these days ?
Simo.
>
>
> >
> >
> > 4) The CLI sections needs more work, especially for non-standard
> > commands like timerule-test.
> >
> >>
> >> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the
> >> CLI functionality (except for the creation of iCalendar strings from
> >> options) for better illustration of the design.
> >>
> >> https://github.com/stlaz/freeipa/tree/timerules_2
> >>
> >> I will add FreeIPA people that recently had some say about this to CC so
> >> that we can get the discussion flowing.
> >
> > Honza
> >
>
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 12:27 PM, Jan Cholasta wrote:
On 26.8.2016 12:21, Martin Basti wrote:
On 26.08.2016 12:13, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to
the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.
I'm not sure if this is user friendly.
You can obviously catch the schema violation and provided a meaningful
error instead.
I don't really have a strong opinion here. My point was to be able to
hold all the attributes of the old type rule to be able to switch back
without losing anything. Then the new objectClass would obviously be
only used so that the older clients don't get the new HBAC rules that
have the restrictions they don't understand.
On the other hand, we do not want the mess from the older rules there
anyway if we want to use capabilities of the newer rule type so it might
be fine. But if user wants to create a new rule from an old one they
have to go through all the old attributes and manually remove their
values which may be a bother for them. Also, I believe that there's code
in SSSD that deals with some of these older attributes and this MIGHT
cause schema violation even on SSSD side if we want to work with older
HBAC rules in the same way as with the newer.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we
have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.
Right, sorry.
Martin^2
4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.
I definitely plan to look into the *test commands a bit more, I only
drafted it quick yesterday.
On the link below is a PROTOTYPE-patched FreeIPA that covers most
of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.
https://github.com/stlaz/freeipa/tree/timerules_2
I will add FreeIPA people that recently had some say about this to
CC so
that we can get the discussion flowing.
Honza
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 12:47 PM, Standa Laznicka wrote:
> On 08/26/2016 12:39 PM, Martin Basti wrote:
>>
>>
>> On 26.08.2016 12:37, Petr Vobornik wrote:
>>> On 08/26/2016 12:23 PM, Martin Basti wrote:
On 26.08.2016 12:20, Alexander Bokovoy wrote:
> On Fri, 26 Aug 2016, Jan Cholasta wrote:
>> On 26.8.2016 11:55, Martin Basti wrote:
>>>
>>> On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
> Hello,
>
> I updated the design of the Time-Based HBAC Policies according
> to the
> discussion we led here earlier. Please check the design page
> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
> biggest
> changes are in the Implementation and Feature Management
> sections. I
> also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes:
memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime
should
be removed from ipaHBACRuleV2.
>>> ad 2) 3)
>>>
>>> Because backward compatibility, ipaHBACRuleV2 must contain all
>>> attributes from ipaHBACRule as MAY
>> Not true.
>>
>>> With current approach, when timerule is added to HBAC, we just
>>> change
>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
>>> attributes that was defined in older HBAC. Removing any attrs from
>>> ipaHBACRuleV2 can cause schema violation.
>> Which is perfectly fine.
>>
>>>
>>> I'm not sure if want to handle this in code (removing deprecated
>>> attributes from HBAC entry when timerule is added)
>> We don't have to do anything. If any of the deprecated attributes are
>> present when you change the object class (which they shouldn't
>> anyway), you'll get schema violation, otherwise it will work just
>> fine.
>>
>>> I realized that AccessTime is MUST for 'ipahbacrule', so when
>>> timerule
>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we
>>> have to
>>> add it back.
>> It is MAY. The only MUST attribute is accessRuleType, but that is
>> deprecated as well and should be removed from ipaHBACRuleV2. We only
>> support allow rules, so when timerule is removed, that's the value
>> you set accessRuleType to.
> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
> Changing to ipaHBACRuleV2 means these rules will not be found by older
> SSSD versions and therefore people will experience problems with older
> clients not being able to use new rules even if they would lack time
> component.
>
Older client do not support timerules, so they should not search for
them. HBAC without timerules will be still have 'ipaHBACRule'
objectclass and will work with old clients. Only HBAC with timerules
will have assigned 'ipaHBACRuleV2'
Martin^2
>>> 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.
>>
> It's exactly that - I will mention it there, then.
Thanks
>> 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?
>>
> Word.
>>>
>>>
>>> 2. About API and CLI: wasn't there an idea to hide/not provide
>>> --icalfile=file.ics and --time=escaped_icalstring options in the first
>>> implementation. So that we can limit the support scope to only a subset
>>> of option(the OPTS part). If arbitrary ical is allowed since the
>>> beginning then we are asking for a lot of bugs filed.
>>>
>>
> Why hide it if there's no real problem with it? The string/content only
> has to be cut down to the restrictions of one event per VCALENDAR but I
> do not see the problem there.
>
OK then.
--
Petr Vobornik
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 12:39 PM, Martin Basti wrote:
On 26.08.2016 12:37, Petr Vobornik wrote:
On 08/26/2016 12:23 PM, Martin Basti wrote:
On 26.08.2016 12:20, Alexander Bokovoy wrote:
On Fri, 26 Aug 2016, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according
to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management
sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes:
memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime
should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just
change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just
fine.
I realized that AccessTime is MUST for 'ipahbacrule', so when
timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we
have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value
you set accessRuleType to.
SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.
Older client do not support timerules, so they should not search for
them. HBAC without timerules will be still have 'ipaHBACRule'
objectclass and will work with old clients. Only HBAC with timerules
will have assigned 'ipaHBACRuleV2'
Martin^2
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.
It's exactly that - I will mention it there, then.
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?
Word.
2. About API and CLI: wasn't there an idea to hide/not provide
--icalfile=file.ics and --time=escaped_icalstring options in the first
implementation. So that we can limit the support scope to only a subset
of option(the OPTS part). If arbitrary ical is allowed since the
beginning then we are asking for a lot of bugs filed.
Why hide it if there's no real problem with it? The string/content only
has to be cut down to the restrictions of one event per VCALENDAR but I
do not see the problem there.
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 12:39 PM, Martin Basti wrote:
>
>
> On 26.08.2016 12:37, Petr Vobornik wrote:
>> On 08/26/2016 12:23 PM, Martin Basti wrote:
>>>
>>> On 26.08.2016 12:20, Alexander Bokovoy wrote:
On Fri, 26 Aug 2016, Jan Cholasta wrote:
> On 26.8.2016 11:55, Martin Basti wrote:
>>
>> On 26.08.2016 11:43, Jan Cholasta wrote:
>>> Hi,
>>>
>>> On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according
to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management
sections. I
also added a short How to Use section.
>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
>>> ipaMemberTimeRule
>>>
>>>
>>> 2) Source hosts are deprecated and thus should be removed from
>>> ipaHBACRuleV2.
>>>
>>>
>>> 3) Since time rules are defined by memberTimeRule, accessTime should
>>> be removed from ipaHBACRuleV2.
>> ad 2) 3)
>>
>> Because backward compatibility, ipaHBACRuleV2 must contain all
>> attributes from ipaHBACRule as MAY
> Not true.
>
>> With current approach, when timerule is added to HBAC, we just change
>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
>> attributes that was defined in older HBAC. Removing any attrs from
>> ipaHBACRuleV2 can cause schema violation.
> Which is perfectly fine.
>
>>
>> I'm not sure if want to handle this in code (removing deprecated
>> attributes from HBAC entry when timerule is added)
> We don't have to do anything. If any of the deprecated attributes are
> present when you change the object class (which they shouldn't
> anyway), you'll get schema violation, otherwise it will work just
> fine.
>
>> I realized that AccessTime is MUST for 'ipahbacrule', so when
>> timerule
>> ('ipahbacrulev2') is removed and somebody deleted accesstime we
>> have to
>> add it back.
> It is MAY. The only MUST attribute is accessRuleType, but that is
> deprecated as well and should be removed from ipaHBACRuleV2. We only
> support allow rules, so when timerule is removed, that's the value
> you set accessRuleType to.
SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.
>>> Older client do not support timerules, so they should not search for
>>> them. HBAC without timerules will be still have 'ipaHBACRule'
>>> objectclass and will work with old clients. Only HBAC with timerules
>>> will have assigned 'ipaHBACRuleV2'
>>>
>>> Martin^2
>> 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?
My point is that the design is missing the explanation.
>
>>
>>
>> 2. About API and CLI: wasn't there an idea to hide/not provide
>> --icalfile=file.ics and --time=escaped_icalstring options in the first
>> implementation. So that we can limit the support scope to only a subset
>> of option(the OPTS part). If arbitrary ical is allowed since the
>> beginning then we are asking for a lot of bugs filed.
>>
>
--
Petr Vobornik
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.08.2016 12:37, Petr Vobornik wrote:
On 08/26/2016 12:23 PM, Martin Basti wrote:
On 26.08.2016 12:20, Alexander Bokovoy wrote:
On Fri, 26 Aug 2016, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value
you set accessRuleType to.
SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.
Older client do not support timerules, so they should not search for
them. HBAC without timerules will be still have 'ipaHBACRule'
objectclass and will work with old clients. Only HBAC with timerules
will have assigned 'ipaHBACRuleV2'
Martin^2
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?
2. About API and CLI: wasn't there an idea to hide/not provide
--icalfile=file.ics and --time=escaped_icalstring options in the first
implementation. So that we can limit the support scope to only a subset
of option(the OPTS part). If arbitrary ical is allowed since the
beginning then we are asking for a lot of bugs filed.
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/26/2016 12:23 PM, Martin Basti wrote:
>
>
> On 26.08.2016 12:20, Alexander Bokovoy wrote:
>> On Fri, 26 Aug 2016, Jan Cholasta wrote:
>>> On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
> Hi,
>
> On 11.8.2016 12:34, Stanislav Laznicka wrote:
>> Hello,
>>
>> I updated the design of the Time-Based HBAC Policies according to the
>> discussion we led here earlier. Please check the design page
>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
>> biggest
>> changes are in the Implementation and Feature Management sections. I
>> also added a short How to Use section.
>
> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
> ipaMemberTimeRule
>
>
> 2) Source hosts are deprecated and thus should be removed from
> ipaHBACRuleV2.
>
>
> 3) Since time rules are defined by memberTimeRule, accessTime should
> be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
>>>
>>> Not true.
>>>
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
>>>
>>> Which is perfectly fine.
>>>
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
>>>
>>> We don't have to do anything. If any of the deprecated attributes are
>>> present when you change the object class (which they shouldn't
>>> anyway), you'll get schema violation, otherwise it will work just fine.
>>>
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
>>>
>>> It is MAY. The only MUST attribute is accessRuleType, but that is
>>> deprecated as well and should be removed from ipaHBACRuleV2. We only
>>> support allow rules, so when timerule is removed, that's the value
>>> you set accessRuleType to.
>>
>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
>> Changing to ipaHBACRuleV2 means these rules will not be found by older
>> SSSD versions and therefore people will experience problems with older
>> clients not being able to use new rules even if they would lack time
>> component.
>>
>
> Older client do not support timerules, so they should not search for
> them. HBAC without timerules will be still have 'ipaHBACRule'
> objectclass and will work with old clients. Only HBAC with timerules
> will have assigned 'ipaHBACRuleV2'
>
> Martin^2
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.
2. About API and CLI: wasn't there an idea to hide/not provide
--icalfile=file.ics and --time=escaped_icalstring options in the first
implementation. So that we can limit the support scope to only a subset
of option(the OPTS part). If arbitrary ical is allowed since the
beginning then we are asking for a lot of bugs filed.
--
Petr Vobornik
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.08.2016 12:20, Alexander Bokovoy wrote:
On Fri, 26 Aug 2016, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value
you set accessRuleType to.
SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.
Older client do not support timerules, so they should not search for
them. HBAC without timerules will be still have 'ipaHBACRule'
objectclass and will work with old clients. Only HBAC with timerules
will have assigned 'ipaHBACRuleV2'
Martin^2
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.8.2016 12:21, Martin Basti wrote:
On 26.08.2016 12:13, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.
I'm not sure if this is user friendly.
You can obviously catch the schema violation and provided a meaningful
error instead.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.
Right, sorry.
Martin^2
4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.
On the link below is a PROTOTYPE-patched FreeIPA that covers most
of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.
https://github.com/stlaz/freeipa/tree/timerules_2
I will add FreeIPA people that recently had some say about this to
CC so
that we can get the discussion flowing.
Honza
--
Jan Cholasta
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.08.2016 12:13, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just fine.
I'm not sure if this is user friendly.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.
Right, sorry.
Martin^2
4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.
On the link below is a PROTOTYPE-patched FreeIPA that covers most
of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.
https://github.com/stlaz/freeipa/tree/timerules_2
I will add FreeIPA people that recently had some say about this to
CC so
that we can get the discussion flowing.
Honza
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Fri, 26 Aug 2016, Jan Cholasta wrote:
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't
anyway), you'll get schema violation, otherwise it will work just
fine.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.
SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.
--
/ Alexander Bokovoy
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.8.2016 11:55, Martin Basti wrote:
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
Not true.
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
Which is perfectly fine.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
We don't have to do anything. If any of the deprecated attributes are
present when you change the object class (which they shouldn't anyway),
you'll get schema violation, otherwise it will work just fine.
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
It is MAY. The only MUST attribute is accessRuleType, but that is
deprecated as well and should be removed from ipaHBACRuleV2. We only
support allow rules, so when timerule is removed, that's the value you
set accessRuleType to.
4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.
On the link below is a PROTOTYPE-patched FreeIPA that covers most of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.
https://github.com/stlaz/freeipa/tree/timerules_2
I will add FreeIPA people that recently had some say about this to CC so
that we can get the discussion flowing.
Honza
--
Jan Cholasta
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 26.08.2016 11:43, Jan Cholasta wrote:
Hi,
On 11.8.2016 12:34, Stanislav Laznicka wrote:
Hello,
I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.
1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule
2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.
3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.
ad 2) 3)
Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY
With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.
I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)
I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.
4) The CLI sections needs more work, especially for non-standard
commands like timerule-test.
On the link below is a PROTOTYPE-patched FreeIPA that covers most of the
CLI functionality (except for the creation of iCalendar strings from
options) for better illustration of the design.
https://github.com/stlaz/freeipa/tree/timerules_2
I will add FreeIPA people that recently had some say about this to CC so
that we can get the discussion flowing.
Honza
--
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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
Hi, On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. 1) Please use the 'ipa' prefix for new attributes: memberTimeRule -> ipaMemberTimeRule 2) Source hosts are deprecated and thus should be removed from ipaHBACRuleV2. 3) Since time rules are defined by memberTimeRule, accessTime should be removed from ipaHBACRuleV2. 4) The CLI sections needs more work, especially for non-standard commands like timerule-test. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 I will add FreeIPA people that recently had some say about this to CC so that we can get the discussion flowing. Honza -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/19/2016 04:06 PM, Martin Basti wrote: On 19.08.2016 12:37, Pavel Vomacka wrote: On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: On 08/12/2016 06:48 PM, Petr Spacek wrote: On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. Thank you for the review! I will add some comments inline. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). Definitely a good idea, I will work that in. 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface = We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. I'm definitely for creating a field where admin can choose a existing time rule when creating a new HBAC. But I'm not sure about possibility to create and define new time rule in dialog for creating new HBAC. I think that mixing these two things together is like a possibility to create a new user when you are creating a user group. Which is mixing two different things together. I can imagine a button like "Create HBAC and add a new time rule to it" which could store new HBAC rule and immediately take admin to the page (or dialog) where admin can create a new time rule with prefilled HBAC rule. But as you write below it would be good to discuss it with some UX designer. I'm not UX guru, but if you add button there and show dialog window to create new timerule and then automatically assign it to the HBACrule it may work for me :) Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All of these points are really good. All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I will add Pavel V. to CC, we may want to discuss this. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) It definitely felt better to be writing it with all the previous knowledge. Thank you! :-) LGTM with all previous comments Thank you for the review, my comments are inline (Nitpick mode enabled: True) 1. It may not be clear from design that client is
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 19.08.2016 12:37, Pavel Vomacka wrote: On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: On 08/12/2016 06:48 PM, Petr Spacek wrote: On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. Thank you for the review! I will add some comments inline. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). Definitely a good idea, I will work that in. 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface = We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. I'm definitely for creating a field where admin can choose a existing time rule when creating a new HBAC. But I'm not sure about possibility to create and define new time rule in dialog for creating new HBAC. I think that mixing these two things together is like a possibility to create a new user when you are creating a user group. Which is mixing two different things together. I can imagine a button like "Create HBAC and add a new time rule to it" which could store new HBAC rule and immediately take admin to the page (or dialog) where admin can create a new time rule with prefilled HBAC rule. But as you write below it would be good to discuss it with some UX designer. I'm not UX guru, but if you add button there and show dialog window to create new timerule and then automatically assign it to the HBACrule it may work for me :) Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All of these points are really good. All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I will add Pavel V. to CC, we may want to discuss this. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) It definitely felt better to be writing it with all the previous knowledge. Thank you! :-) LGTM with all previous comments (Nitpick mode enabled: True) 1. It may not be clear from design that client is actually SSSD, and not IPA CLI client. Please write explicitly there that HBAC time rules are
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/16/2016 08:21 AM, Stanislav Laznicka wrote: On 08/12/2016 06:48 PM, Petr Spacek wrote: On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. Thank you for the review! I will add some comments inline. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). Definitely a good idea, I will work that in. 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface = We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. I'm definitely for creating a field where admin can choose a existing time rule when creating a new HBAC. But I'm not sure about possibility to create and define new time rule in dialog for creating new HBAC. I think that mixing these two things together is like a possibility to create a new user when you are creating a user group. Which is mixing two different things together. I can imagine a button like "Create HBAC and add a new time rule to it" which could store new HBAC rule and immediately take admin to the page (or dialog) where admin can create a new time rule with prefilled HBAC rule. But as you write below it would be good to discuss it with some UX designer. Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All of these points are really good. All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I will add Pavel V. to CC, we may want to discuss this. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) It definitely felt better to be writing it with all the previous knowledge. Thank you! :-) -- Pavel^3 Vomacka -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On Tue, 16 Aug 2016, Stanislav Laznicka wrote: On 08/12/2016 06:48 PM, Petr Spacek wrote: On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. Thank you for the review! I will add some comments inline. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). Definitely a good idea, I will work that in. 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. If the attribute can be used, let's use it. We can limit multiple values in the framework and actively complain about multi-valued accessTime. Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. accessTime was part of HBAC rule but when SELinuxUserMap support was added, HBAC lost accessTime functionality --- that's why ipaSELinuxUserMap object class carries accessTime attribute, to specify the time when associated HBAC rule applies. This is one more argument to re-use accessTime attribute. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 08/12/2016 06:48 PM, Petr Spacek wrote: On 11.8.2016 12:34, Stanislav Laznicka wrote: Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. Thank you for the review! I will add some comments inline. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. My idea was that we allow users prepare a few time rule objects before filling them with the actual times. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). Definitely a good idea, I will work that in. 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? I believe that the accessTime attribute was originally brought to IPA when there was an implementation of time policies for HBAC objects and it's been rotting there ever since those capabilities were removed. We may eventually use a new attribute for storage of the time strings as accessTime by definition is multi-valued which is not what's currently desired (although we may end up with it some day in the future). However, I don't think any other use of accessTime should be a problem as it's been obsoleted for a long time. Why is it even in ipaSELinuxUserMap object class? I'm sorry to say I have no idea. I used it for what it originally was - a means for storing time strings at HBAC rules. Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface = We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I will add Pavel V. to CC, we may want to discuss this. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) It definitely felt better to be writing it with all the previous knowledge. Thank you! :-) -- 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
Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
On 11.8.2016 12:34, Stanislav Laznicka wrote: > Hello, > > I updated the design of the Time-Based HBAC Policies according to the > discussion we led here earlier. Please check the design page > http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest > changes are in the Implementation and Feature Management sections. I also > added a short How to Use section. Nice page! On the high level it all makes sense. ad LDAP schema == 1) Why accessTime attribute is MAY in ipaTimeRule object class? Does it make sense to have the object without accessTime? I do not think so. Also, it could be good to add description attribute to the object class and incorporate it into commands (including find). 2) Besides all this, I spent few minutes in dark history of IPA. The accessTime attribute was introduced back in 2009 in commit "55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for IPAv2". The commit does not contain any reasoning for the change but I can see that the attribute is already used as MAY in old object classes ipaHBACRule and ipaSELinuxUserMap. Is any of these a problem? Why is it even in ipaSELinuxUserMap object class? Commit 55512dc938eb4a9a6655e473beab587e340af55c does not mention any reason for doing so. I cannot see any other problem so the low-level stuff is good and can be implemented. ad User interface = We need to polish the user interface so it really usable. At least the web interface should contain some shortcuts. E.g. when I'm adding a new HBAC rule, the "time" section should contain also "something" to immediately add new time rule so I do not need to go to time rules first and then go back to HBAC page. Similarly, dialog for rule modification should allow to easily change all the values, warn if time rules is shared, and also have an easy way to 'disconnect' the time rule, i.e. make a copy of it and edit only the new copy (instead of the shared original). All these are user interface things not affecting the low-level stuff. Maybe you should sat down with some UX designer, talk about these cases and draw some hand-made pictures. I do not believe that this will require any changes in schema so you can polish SSSD and framework implementation in meantime. > On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI > functionality (except for the creation of iCalendar strings from options) for > better illustration of the design. > > https://github.com/stlaz/freeipa/tree/timerules_2 Honestly I did not look at the code today :-) Overall, I'm glad to see current proposal. After so many iteration, we reached something which does not have any glaring problem :-) -- Petr^2 Spacek -- 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
[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies
Hello, I updated the design of the Time-Based HBAC Policies according to the discussion we led here earlier. Please check the design page http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest changes are in the Implementation and Feature Management sections. I also added a short How to Use section. On the link below is a PROTOTYPE-patched FreeIPA that covers most of the CLI functionality (except for the creation of iCalendar strings from options) for better illustration of the design. https://github.com/stlaz/freeipa/tree/timerules_2 I will add FreeIPA people that recently had some say about this to CC so that we can get the discussion flowing. Thanks, Standa -- 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
