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..