[Freeipa-devel] Proposal: drop DENY rules from HBAC

[Simo Sorce]

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