diff options
Diffstat (limited to 'install/html/hbac-deny-remove.html')
| -rw-r--r-- | install/html/hbac-deny-remove.html | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/install/html/hbac-deny-remove.html b/install/html/hbac-deny-remove.html new file mode 100644 index 000000000..987819cd2 --- /dev/null +++ b/install/html/hbac-deny-remove.html @@ -0,0 +1,82 @@ +<!DOCTYPE html> +<html> +<head> +<meta charset="utf-8"> + <title>IPA: Identity Policy Audit</title> + + <script type="text/javascript" src="../ui/jquery.js"></script> + + <link rel="stylesheet" type="text/css" href="../ui/jquery-ui.css" /> + <link rel="stylesheet" type="text/css" href="ipa_error.css" /> + + +</head> + +<body id="header-bg"> + + <div class="container_1"> + <div class="header-logo"> + <img src="../ui/ipalogo.png" /> + </div> + <div class="textblockkrb"> + <h1>Removal of HBAC Deny Rules.</h1> + <p>FreeIPA has dropped support for DENY rules from the HBAC + specification. </p> + <p>The former design of HBAC specifies that<p> + <ol> + <li> If no ALLOW rules match, access is denied</li> + <li> If one or more ALLOW rules match and no DENY rules match, + access is allowed</li> + <li>If one or more DENY rules match, access is denied</li> + </ol> + <p>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]</P> + + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + + <p>Given these edge cases (and performance issues of the noted + workaround), The FreeIPA team decided to drop DENY rules from the + HBAC specification and limit HBAC only to ALLOW rules (which are + much safer). Beyond the obvious advantages for our implementation, + this should make it less complex for users to write their rules.</p> + + <p>[1] Some rules are complex to simulate, such as "Allow access from + all PAM services EXCEPT telnet". But a safer and clearer + implementation approach does all access via whitelist. If a FreeIPA + implementation is using an exception rule, the administrators + should re-evaluate the justification. + </p> + </div> + + </div> + +</body> + +</html> |