diff options
| author | Endi S. Dewata <edewata@redhat.com> | 2011-10-24 18:18:10 -0500 |
|---|---|---|
| committer | Endi S. Dewata <edewata@redhat.com> | 2011-10-26 12:53:28 +0000 |
| commit | f168afbeb6e88e6ba66d7472529c35ed78dc6bc0 (patch) | |
| tree | ebadbb98c5c688c9c7bb00f81598868fb7678057 /install/html | |
| parent | 0450934e366c37d01fe84a2c23ed196bf8dd6f89 (diff) | |
| download | freeipa-f168afbeb6e88e6ba66d7472529c35ed78dc6bc0.tar.gz freeipa-f168afbeb6e88e6ba66d7472529c35ed78dc6bc0.tar.xz freeipa-f168afbeb6e88e6ba66d7472529c35ed78dc6bc0.zip | |
Removed HBAC deny rule warning.
The HBAC deny rule is no longer supported so it's no longer necessary
to show the warning.
Ticket #1444
Diffstat (limited to 'install/html')
| -rw-r--r-- | install/html/Makefile.am | 1 | ||||
| -rw-r--r-- | install/html/hbac-deny-remove.html | 83 |
2 files changed, 0 insertions, 84 deletions
diff --git a/install/html/Makefile.am b/install/html/Makefile.am index c310be6d2..46e8683c8 100644 --- a/install/html/Makefile.am +++ b/install/html/Makefile.am @@ -5,7 +5,6 @@ app_DATA = \ ssbrowser.html \ browserconfig.html \ unauthorized.html \ - hbac-deny-remove.html \ ipa_error.css \ $(NULL) diff --git a/install/html/hbac-deny-remove.html b/install/html/hbac-deny-remove.html deleted file mode 100644 index 7debfea76..000000000 --- a/install/html/hbac-deny-remove.html +++ /dev/null @@ -1,83 +0,0 @@ -<!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="../ui/ipa.css" /> - <link rel="stylesheet" type="text/css" href="ipa_error.css" /> - - -</head> - -<body class="info-page"> - - <div class="container_1"> - <div class="header-logo"> - <img src="../ui/ipalogo.png" /><img src="../ui/ipabanner.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> |