[ 
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)

Reply via email to