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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
