[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977549#comment-14977549
]
Madhan Neethiraj commented on RANGER-606:
-----------------------------------------
[~yzhou2001] Thanks for sharing your analysis on current policy model (lack of
DENY) and the proposed update to support DENY. As you rightly pointed out, the
current model does make it difficult-to-ascertain negative state, which is
resolved with the support for DENY in the policy model. With priority to DENY
over ALLOW, ensuring that an user or a group has access to a resource does
require making sure that access would not be denied by DENY in any policy.
I think time-ordering approach you suggested would help. However, it can get
tricky when multiple policies are applicable for the resource being accessed.
For example, consider that case where there is a policy for entire "finance"
database; another policy for subset of tables in finance database - like
"accounts". Lets assume the following sequence of policy updates:
1. policy-1: allow select access to all tables in finance database for users
in finance group
2. policy-2: deny any access to finance.accounts table for every one except
for users "user1, user2, user3"
3. policy-1: update to allow select access to all tables in finance database
for user "audit1" (who is not in finance group)
4. policy-2: update to allow select access to finance.accounts table for
another user "user4" (in addition to "user1, user2, user3", and continue to
deny everyone else)
In this case, "audit1" would have access to finance.accounts table only during
the interval between update #3 and #4 above. Because after #4, policy-2 becomes
the most recently updated policy and hence would deny everyone except "user1,
user2, user3, user4". It looks like the issue of "difficult-to-ascertain"
remains the same..perhaps it makes it more difficult to ascertain as it depends
on the order of policy updates - perhaps by different policy administrators.
I think an easier to understand model would be where only one policy authorizes
access to a resource. In such scenarios, the policy administrators can specify
the order in which the access control entries should be evaluated. The first
entry that matches the request would decide whether access is granted or
denied. However, this takes away the flexibility to be able to define
authorization at various levels - database/table/columns or directory
hierarchies.
Having a way to "exclude" users/groups from "allow/deny" conditions (which is
available with the deny support update) should be able to help achieve the
desired results - however, it does require reviewing all applicable policies
for the resource.
> Add support for deny policies
> ------------------------------
>
> Key: RANGER-606
> URL: https://issues.apache.org/jira/browse/RANGER-606
> Project: Ranger
> Issue Type: Bug
> Components: admin, plugins
> Affects Versions: 0.5.0
> Reporter: Madhan Neethiraj
> Assignee: Madhan Neethiraj
> Fix For: 0.5.0
>
>
> Currently Ranger supports creation of policies that can allow access when
> specific conditions are met (for example, resources, user, groups,
> access-type, custom-conditions..). In addition to this, having the ability to
> create policies that deny access for specific conditions will help address
> many usecases, like:
> - deny access for specific users/groups/ip-addresses/time-of-day
> - deny access when specific conditions are met - like
> resources/users/groups/access-types/custom-conditions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)