Re: [Freeipa-devel] Proposal: drop DENY rules from HBAC
On Wed, 2011-06-29 at 16:25 -0400, Jakub Hrozek wrote: By removing the deny rules, do we break compatibility with anything else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? Ok we've had a somewhat heated discussion internally about how to deal with the transition phase for those admins that decided to use HBAC DENY rules. Hopefully very few did and so very few people will actually be impacted, but we need to handle those cases the best we can to avoid security issues for those users. Here is a rough plan I'd like to get both developers *AND* users feedback on if you care about it. The premise to the following plan is that very few administrators, unfortunately, carefully read release notes before upgrading, so simply dropping and ignoring DENY rules is felt as something we can't do. We split the solution in 2 parts, one on the SSSD side (the only client currently able to understand IPA HBAC rules), and one on the server side. SSSD: Inconveniencing clients is probably the easiest way to cause the least disruption and attracting the administrators attention. The idea here is to treat any DENY rule as actually a DENY-ALL rule. Basically causing any login attempt for any service to fail as soon as the new sssd package will be installed. Even though admins normally do not read release notes, they still do a few test upgrades before upgrading the whole set of clients they administer. By having SSSD deny logins if any DENY rule is found (and spamming the log with pointers at the same time) we hope to give admins a good enough wake up something changed call. This change will be prominently advertised in SSSD release notes. Also to ease the pain for those places where the Server and client admins are different groups, we plan to add a transitional configuration option. This option will allow admins to ignore DENY rules entirely. The option will default to the DENYALL behavior described above, but admins will be able to toggle it to ignore so they can keep testing the client, while they make sure to warn the Server admins that DENY rules support is going to be dropped. FreeIPA: On the server side instead we will add 2 visual cues to the WebUI and probably something to the CLI commands used to manage HBAC rules. In the WebUI, pending UXD and UI developers approval/feedback we will have a prominent error message in the main page only for administrators that are allowed to manage HBAC rules. This warning will be shown if any DENY rule exist on the server. In the HBAC pages, deny rules will be highlighted and text explaining they are not supported anymore and need to be removed will be shown. These warnings will be dropped down the road after 1 more point release. Of course Release notes will prominently highlight this change so that most admins will be prepared to handle this change. Hopefully people will have enough cues to properly handle the situation. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Proposal: drop DENY rules from HBAC
We discussed today on the FreeIPA status meeting the possibility of dropping support for DENY rules from the HBAC specification. I'm submitting it for discussion. Specifically, I'm looking to hear whether there any any FreeIPA admins out there that have a strong opinion on whether the DENY rules need to be included. The current design of HBAC specifies that 1) If no ALLOW rules match, access is denied 2) If one or more ALLOW rules match and no DENY rules match, access is allowed. 3) If one or more DENY rules match, access is denied. Thus, DENY rules exist only to provide exceptions from the ALLOW rules. There exists no ALLOW+DENY combination that cannot be constructed from ALLOW rules only.[1] DENY rules introduce a lot of edge-cases for evaluation. The most important of which is the availability of the group membership for the user logging in. Depending on the mechanism used to log in (for example, GSSAPI over SSH or cross-realm Kerberos trust where the user is provided by the PAC), SSSD's cache may not have a complete list of groups for this user. If the login is occurring during offline mode (where SSSD cannot contact the LDAP server to refresh the user's groups), SSSD cannot determine whether DENY rules would match for the user. This therefore translates into a potential security issue. We implemented a workaround in the SSSD evaluator to resolve this by guaranteeing that we do a full lookup of all groups referenced by rules while we are retrieving the rules from FreeIPA. However, this requires at least one additional lookup against the LDAP server (possibly many if there is need to resolve nestings). This results in a significantly slower login while online. We also have issues related to source host evaluation. Some applications will provide an IP address instead of a hostname in the pam_rhost attribute. Our only recourse here is to perform a reverse-DNS lookup to try and identify the real hostname(s) of the server. However, in many real-world environments, reverse DNS is unavailable or misconfigured. In the case of ALLOW rules, this would lead to a match failure and an implicit denial. However, a failure to properly match a DENY rule can result in unexpected access being granted. This is a potentially serious security issue. Given these edge cases (and performance issues of the noted workaround), I propose that we should drop DENY rules from the HBAC specification and limit ourselves only to ALLOW rules (which are much safer). Beyond the obvious advantages for our implementation, I believe that this will be less complex for users to write their rules. [1] Some rules are complex to simulate, such as Allow access from all PAM services EXCEPT telnet. But in a sane environment, all access should be via whitelist. If a customer is using an exception rule, they should re-evaluate this. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposal: drop DENY rules from HBAC
On 06/29/2011 04:00 PM, Stephen Gallagher wrote: We discussed today on the FreeIPA status meeting the possibility of dropping support for DENY rules from the HBAC specification. I'm submitting it for discussion. Specifically, I'm looking to hear whether there any any FreeIPA admins out there that have a strong opinion on whether the DENY rules need to be included. The current design of HBAC specifies that 1) If no ALLOW rules match, access is denied 2) If one or more ALLOW rules match and no DENY rules match, access is allowed. 3) If one or more DENY rules match, access is denied. Thus, DENY rules exist only to provide exceptions from the ALLOW rules. There exists no ALLOW+DENY combination that cannot be constructed from ALLOW rules only.[1] DENY rules introduce a lot of edge-cases for evaluation. The most important of which is the availability of the group membership for the user logging in. Depending on the mechanism used to log in (for example, GSSAPI over SSH or cross-realm Kerberos trust where the user is provided by the PAC), SSSD's cache may not have a complete list of groups for this user. If the login is occurring during offline mode (where SSSD cannot contact the LDAP server to refresh the user's groups), SSSD cannot determine whether DENY rules would match for the user. This therefore translates into a potential security issue. We implemented a workaround in the SSSD evaluator to resolve this by guaranteeing that we do a full lookup of all groups referenced by rules while we are retrieving the rules from FreeIPA. However, this requires at least one additional lookup against the LDAP server (possibly many if there is need to resolve nestings). This results in a significantly slower login while online. We also have issues related to source host evaluation. Some applications will provide an IP address instead of a hostname in the pam_rhost attribute. Our only recourse here is to perform a reverse-DNS lookup to try and identify the real hostname(s) of the server. However, in many real-world environments, reverse DNS is unavailable or misconfigured. In the case of ALLOW rules, this would lead to a match failure and an implicit denial. However, a failure to properly match a DENY rule can result in unexpected access being granted. This is a potentially serious security issue. Given these edge cases (and performance issues of the noted workaround), I propose that we should drop DENY rules from the HBAC specification and limit ourselves only to ALLOW rules (which are much safer). Beyond the obvious advantages for our implementation, I believe that this will be less complex for users to write their rules. [1] Some rules are complex to simulate, such as Allow access from all PAM services EXCEPT telnet. But in a sane environment, all access should be via whitelist. If a customer is using an exception rule, they should re-evaluate this. I think that an explicit allow list is usually way better because with deny rules it's easy to fail to enumerate all entities that should be denied, resulting in allowing access we didn't want to. However, does anyone still remember why we opted for deny rules during design phase in the first place? Was it a compatibility with some existing system (that our users might be migrating from) or just to provide a convenient construct to our users? By removing the deny rules, do we break compatibility with anything else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposal: drop DENY rules from HBAC
On Wed, 2011-06-29 at 16:25 -0400, Jakub Hrozek wrote: On 06/29/2011 04:00 PM, Stephen Gallagher wrote: We discussed today on the FreeIPA status meeting the possibility of dropping support for DENY rules from the HBAC specification. I'm submitting it for discussion. Specifically, I'm looking to hear whether there any any FreeIPA admins out there that have a strong opinion on whether the DENY rules need to be included. The current design of HBAC specifies that 1) If no ALLOW rules match, access is denied 2) If one or more ALLOW rules match and no DENY rules match, access is allowed. 3) If one or more DENY rules match, access is denied. Thus, DENY rules exist only to provide exceptions from the ALLOW rules. There exists no ALLOW+DENY combination that cannot be constructed from ALLOW rules only.[1] DENY rules introduce a lot of edge-cases for evaluation. The most important of which is the availability of the group membership for the user logging in. Depending on the mechanism used to log in (for example, GSSAPI over SSH or cross-realm Kerberos trust where the user is provided by the PAC), SSSD's cache may not have a complete list of groups for this user. If the login is occurring during offline mode (where SSSD cannot contact the LDAP server to refresh the user's groups), SSSD cannot determine whether DENY rules would match for the user. This therefore translates into a potential security issue. We implemented a workaround in the SSSD evaluator to resolve this by guaranteeing that we do a full lookup of all groups referenced by rules while we are retrieving the rules from FreeIPA. However, this requires at least one additional lookup against the LDAP server (possibly many if there is need to resolve nestings). This results in a significantly slower login while online. We also have issues related to source host evaluation. Some applications will provide an IP address instead of a hostname in the pam_rhost attribute. Our only recourse here is to perform a reverse-DNS lookup to try and identify the real hostname(s) of the server. However, in many real-world environments, reverse DNS is unavailable or misconfigured. In the case of ALLOW rules, this would lead to a match failure and an implicit denial. However, a failure to properly match a DENY rule can result in unexpected access being granted. This is a potentially serious security issue. Given these edge cases (and performance issues of the noted workaround), I propose that we should drop DENY rules from the HBAC specification and limit ourselves only to ALLOW rules (which are much safer). Beyond the obvious advantages for our implementation, I believe that this will be less complex for users to write their rules. [1] Some rules are complex to simulate, such as Allow access from all PAM services EXCEPT telnet. But in a sane environment, all access should be via whitelist. If a customer is using an exception rule, they should re-evaluate this. I think that an explicit allow list is usually way better because with deny rules it's easy to fail to enumerate all entities that should be denied, resulting in allowing access we didn't want to. This is exactly the problem with Deny rules in general However, does anyone still remember why we opted for deny rules during design phase in the first place? Was it a compatibility with some existing system (that our users might be migrating from) or just to provide a convenient construct to our users? I think we overlooked the drawbacks to implementations when we decided the format. I think I raised some mild concern due to the pain I see with Ms-ACLs and deny rules, but there it is worse because rules are also ordered. So I think I acked deny rules as a convenient construct hoping deny rules wouldn't be that bad if not ordered. Clearly that was a mistake. I now think deny rules are really a technical issue, and convenience shouldn't be allowed to rule in this case. By removing the deny rules, do we break compatibility with anything else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? No. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposal: drop DENY rules from HBAC
I think that an explicit allow list is usually way better because with deny rules it's easy to fail to enumerate all entities that should be denied, resulting in allowing access we didn't want to. However, does anyone still remember why we opted for deny rules during design phase in the first place? IMO it was convenience. Was it a compatibility with some existing system (that our users might be migrating from) or just to provide a convenient construct to our users? No other system we know of does this. By removing the deny rules, do we break compatibility with anything else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? Not that we know of. We break Fedora compatibility but we can handle it with the smart upgrade script that detects the presence of the deny rules and bails out before updating the system asking user to fix deny rules manually before updating. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
