mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-01-21 05:43:11 -06:00
83 lines
3.7 KiB
HTML
83 lines
3.7 KiB
HTML
|
<!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>
|