Hi, FreeIPA and SSSD communities!
I am working on adding URI to HBAC as my thesis [1]. The goal is to control access not only based on (user, host, service), but on (user, host, service, resource's URI).
I created a patch for FreeIPA [2] so it is capable of storing URI as part of HBAC rule. I created a patch for SSSD [3] so it is able to get this URI from FreeIPA and use it in HBAC evaluation.
I still need to develop a part of SSSD receiving URI-aware requests. It will either be an enhancement of Infopipe or I will use PAM responder (any suggestions?).
I wanted to kindly ask you for review and your opinions on the patches and generally on my approach. This would be my first contribution to FreeIPA and SSSD so there might be bugs. What do you think?
Btw, is there some better place to share patches than a pasting tool? Maybe some form of pull request?
Thanks for your opinions!
[1] https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-i... [2] http://pastebin.com/rsHzXeAR [3] http://pastebin.com/atcZMuP1
On Fri, Feb 26, 2016 at 01:15:59PM +0100, Lukáš Hellebrandt wrote:
Hi, FreeIPA and SSSD communities!
I am working on adding URI to HBAC as my thesis [1]. The goal is to control access not only based on (user, host, service), but on (user, host, service, resource's URI).
I created a patch for FreeIPA [2] so it is capable of storing URI as part of HBAC rule. I created a patch for SSSD [3] so it is able to get this URI from FreeIPA and use it in HBAC evaluation.
I still need to develop a part of SSSD receiving URI-aware requests. It will either be an enhancement of Infopipe or I will use PAM responder (any suggestions?).
I wanted to kindly ask you for review and your opinions on the patches and generally on my approach. This would be my first contribution to FreeIPA and SSSD so there might be bugs. What do you think?
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..?
Btw, is there some better place to share patches than a pasting tool? Maybe some form of pull request?
You can clone SSSD on github and publish a branch in your clone https://github.com/SSSD/sssd
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.
But first things first, I want to make the whole concept work and then make in more complicated. In this phase, I need to either enhance Infopipe or PAM responder so I can have the first working iteration. At this point, I don't even have a good way to test changes - although SSSD gets URI from FreeIPA, it isn't capable of receiving requests containing URI.
Btw, is there some better place to share patches than a pasting tool? Maybe some form of pull request?
You can clone SSSD on github and publish a branch in your clone https://github.com/SSSD/sssd
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?
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". 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.
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 :)
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..
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? 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).
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).
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..
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.
One possibility is to treat the prefix hostname/ as separate "object" to hostname/admin/. So whatever allow rules you put in for hostname/ will not be inherited / will not affect hostname/admin/.
On Mon, Feb 29, 2016 at 12:44:01PM +0100, Jakub Hrozek wrote:
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..
I don't really like this approach. You won't be able to do an "OR" operation, granting access to users from group1 and from group2 (meaning, user in either of those groups but not necessarily in both). Yes, you likely could create separate nested user group for that but the problem is, in many environments the application admin will have enough problems getting the IPA admins create the HBAC rules for them, but creating the extra user groups might be frowned upon by their IT department.
Ideally the premissions should be able to work with the existing groups and users.
On Mon, Feb 29, 2016 at 03:30:12PM +0100, Jakub Hrozek wrote:
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..
But with the evaluation you've outlined, it's only to place additional restriction on the rule, isn't it?
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
Is the problem really evaluating the rule or finding the rule? I thought our biggest worry is that the rule will not be seen at all.
And if we require all rules to pass, failure to find the last rule (and evaluate) when all previous have passed, will allow the access. To me, requiring all ruless to pass means that each additional rule is an effective deny on anything it does not match. Yes, if we are aware of the rule existence, we deny the access at worse, but if we miss the rule existence altogether, we've just granted access we were not supposed to grant.
On Mon, Feb 29, 2016 at 04:23:18PM +0100, Jan Pazdziora wrote:
On Mon, Feb 29, 2016 at 12:44:01PM +0100, Jakub Hrozek wrote:
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..
I don't really like this approach. You won't be able to do an "OR" operation, granting access to users from group1 and from group2 (meaning, user in either of those groups but not necessarily in both). Yes, you likely could create separate nested user group for that but the problem is, in many environments the application admin will have enough problems getting the IPA admins create the HBAC rules for them, but creating the extra user groups might be frowned upon by their IT department.
I must be missing something, why can't you add both groups to the rule?
(The rules with URIs would match with an AND, the objects referenced in the rules already match with an OR..)
On Mon, Feb 29, 2016 at 04:29:05PM +0100, Jan Pazdziora wrote:
On Mon, Feb 29, 2016 at 03:30:12PM +0100, Jakub Hrozek wrote:
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..
But with the evaluation you've outlined, it's only to place additional restriction on the rule, isn't it?
Nope, that's not how the groups work. I have a rule on my test IPA server that looks like this: Rule name: ad_allowed_rhel5 Enabled: TRUE User Groups: ad_allowed, admins Hosts: unidirect.ipa.test, centos5.ipa.test, nss-pam-ldapd.ipa.test Services: system-auth, su, su-l
Anyone from group ad_allowed or group admins can log in to the hosts listed in the rule with su, su-l or system-auth PAM services.
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
Is the problem really evaluating the rule or finding the rule? I thought our biggest worry is that the rule will not be seen at all.
And if we require all rules to pass, failure to find the last rule (and evaluate) when all previous have passed, will allow the access. To me, requiring all ruless to pass means that each additional rule is an effective deny on anything it does not match. Yes, if we are aware of the rule existence, we deny the access at worse, but if we miss the rule existence altogether, we've just granted access we were not supposed to grant.
But I guess I understand where we're talking past one another -- is it when the URIs overlap?
Yes, in that case you're right..
On Mon, Feb 29, 2016 at 05:05:41PM +0100, Jakub Hrozek wrote:
On Mon, Feb 29, 2016 at 04:23:18PM +0100, Jan Pazdziora wrote:
I don't really like this approach. You won't be able to do an "OR" operation, granting access to users from group1 and from group2 (meaning, user in either of those groups but not necessarily in both). Yes, you likely could create separate nested user group for that but the problem is, in many environments the application admin will have enough problems getting the IPA admins create the HBAC rules for them, but creating the extra user groups might be frowned upon by their IT department.
I must be missing something, why can't you add both groups to the rule?
(The rules with URIs would match with an AND, the objects referenced in the rules already match with an OR..)
Ah, got it. I thought you had an AND in the rules as well.
Sorry about the noise.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Pazdziora -
Lukáš Hellebrandt