ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-606) Add support for deny policies
Date Wed, 28 Oct 2015 20:48:27 GMT

    [ https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979203#comment-14979203
] 

Yan commented on RANGER-606:
----------------------------

[~madhan.neethiraj] Thanks for the explanation and the example use case. 

To resolve the mentioned difficulty of the example, there are two alternative approaches.

The first is to clearly define the semantics of saving a policy. That is, a (time-ordered)
policy is an atomic body whose component “policy items”, once saved, are atomically committed
as a whole. So the security admin needs to be aware of the consequences of saving a potentially
outdated policy again after updating. Or he can just use a separate policy. Or even the “overwriting”
effect is probably what he has hoped for to, say, reestablish an older policy.

The second and more delicate approach is to timestamp the individual “policy items” so
that only the newest items are timestamped and saved. This approach essentially will treat
the policy as a grouping/tagging mechanism for the policy items for management purposes. 

In summary, the difficulty of the example use case seems to be actually a question of scoping/granularity
 of policies and/or the commit semantics of them. It does not mean new privilege conflicts
introduced by the time-ordering. 

Basically over time security systems will evolve and may well become quite complex and harder
to grasp from the top of head. Validation may well be necessary. Conflicts may well appear
and ideally should be resolved as much as possible. 

Time-stamped/versioned policies also carry an advantage of good traceability and allow for
powerful analysis on the policies and their evolutions, which could well be another added
value compared with component, native systems.

Lastly, there might be a subtle difference between "allow/deny" and "grant/revoke". DENY might
mean a "hard" refusal so that privileges are removed outright and without considerations of
other factors such as on hierarchal resources or by a hierarchal entity(users and groups)
 if such conflicts were to be resolved in a permissive manner. So maybe "Grant/Revoke" are
better terms than "Allow/Deny" given the current permissive resolution of conflicts.

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

Mime
View raw message