summaryrefslogtreecommitdiffstats
path: root/install/html
diff options
context:
space:
mode:
authorAdam Young <ayoung@redhat.com>2011-07-05 17:59:05 -0400
committerEndi S. Dewata <edewata@redhat.com>2011-07-06 21:52:00 +0000
commite4a444ba8159f890daa124d1c546b977a91b9f32 (patch)
tree3a8110eaff3d2d695c4a0592f0f920b361a6a4c3 /install/html
parentaca908e1e4d08d52a95edca2013c510abe2d1788 (diff)
downloadfreeipa-e4a444ba8159f890daa124d1c546b977a91b9f32.tar.gz
freeipa-e4a444ba8159f890daa124d1c546b977a91b9f32.tar.xz
freeipa-e4a444ba8159f890daa124d1c546b977a91b9f32.zip
HBAC deny warning
shows dialog if there are any HBAC deny rules. Dialog provides option to navigate to the HBAC page. Deny rules have their rule type value show up in red. Only shows up fro administrators, not for self service users. https://fedorahosted.org/freeipa/ticket/1421
Diffstat (limited to 'install/html')
-rw-r--r--install/html/Makefile.am1
-rw-r--r--install/html/hbac-deny-remove.html82
2 files changed, 83 insertions, 0 deletions
diff --git a/install/html/Makefile.am b/install/html/Makefile.am
index 46e8683c8..c310be6d2 100644
--- a/install/html/Makefile.am
+++ b/install/html/Makefile.am
@@ -5,6 +5,7 @@ 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
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>