On Mon, Feb 29, 2016 at 12:56:55PM +0100, Lukáš Hellebrandt wrote:
On 02/29/2016 12:44 PM, Jakub Hrozek wrote:
On Mon, Feb 29, 2016 at 11:50:06AM +0100, Lukáš Hellebrandt wrote:
On 02/28/2016 11:42 AM, Jakub Hrozek wrote:
On Fri, Feb 26, 2016 at 02:03:37PM +0100, Lukáš Hellebrandt wrote:
First question I have is that the URLs only match on complete string match. From past conversations I thought we wanted to add a more granular evaluation..?
I am planning to interpret URI as a prefix. However, there might be problem getting enough granularity because FreeIPA has dropped DENY rules: it will be hard to get some behaviors, e.g. "Allow access to hostname/* but not to hostname/admin/*". I do not know yet how to solve this.
Wouldn't it help if all rules that match URI-wise need to allow the person requesting the resource?
I am not sure if I understand. The problem is, I do not know how to make a rule to allow "everything except".
Just don't do it, the current HBAC rules don't support that either :)
That's probably the way to go for now, I need to make some basic working example first.
E.g., allow every URI that does NOT start with $(hostname)/admin/ . It would be possible if there was finite number of prefixes other than $(hostname)/admin , but it might not be the case.
In this example "hostname" would be an HBAC service. Then there might be additional URI rule "/myapp/*" that would be permitted for the 'appusers' group and an URI rule "myapp/admin*" that would be permitted for the 'appadmins' groups. An attempt to access anything under "myapp/admin" would match both URIs, but unless the user requesting access was a member of appusers, one of the two rules wouldn't match and access would be denied..
So, effectively, there would be no way to make some URI accessible to more than one group?
There is nothing preventing you from adding more groups to a single rule..
And if I understand that example correctly, users from 'appadmins' wouldn't be allowed access anywhere (including "/myapp/admin") because of the very same reason users from 'appusers' wouldn't be (not all rules matching "/myapp/admin" URI-wise allow the 'appadmins' group).
Any user requesting a resource would be able to access a resource as long as they are permitted access to /all/ rules matching the resource URLs.
So yeah, if you had myapp/ui, myapp/settings and myapp/admin and wanted appusers to access ui and settings, then you'd have to create rules for myapp/ui and myapp/settings as well..
Still, this beats creating deny rules. Every single time we added deny rules in any form or shape to sssd we ended up regretting that decision after some time..
(One repeating reason is that a failure to evaluate an allow rule causes a denial of service at worst, a failure to evalute a deny rule is a CVE..)
Furthermore, this would require not only evaluating rules of the matching (service and hostname and) user group, but of all the rules (with matching service and hostname).
Sure, but the clients typically cache the rules, so downloading them is not too much of a concern IMO.
btw I'm sure we're not the first ones to be solving this problem, I would suggest to look into how access rules are evaluated and set in i.e webservers..