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

Reply via email to