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 Fri, 06 Nov 2015 00:46:27 GMT

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

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

[~bganesan] Thanks for explanation. I'm sorry that I did not make my points, which are rephrased/reorganised
below clear. Please take a look.

1) I'm not sure about the role of Ranger Policies. If they represent the current *state* of
the security system, they should capture and persistent the final state of the security system
which will be consulted when the authorization requests come in. 
2) If the policies represent series of *actions* that are performed to (re)establish the final
state, then some rules need to be present to perform these actions to ascertain the final
state, either behind scenes at policy creation/modification and persistent on disk, or at
the authorization request time, which would be very inefficient. Examples of such rules are
execution in time sequence, or priority-based (like priority of DENY over GRANT).
3) My guess is that the policies now represent the states, and not actions. Please correct
me if I am wrong here. This is also what FS(HDFS) and many SQL products seem to adopt, namely
their authorization decisions are  based on security states that are changed by actions that
are *not* recorded after execution once.
4) If policies are states,  there could be various actions to work on them. The actions do
not need to be recorded or persistent after executed once. They could be recorded, however,
for future auditing/analysis purposes.

Given these points, my opinions in my last comment are:
1) Separate action clearly from states. Currently, the GRANT/REVOKE action is actually realised
through adding/removing the states, i.e., the policy items. If more convenient ways of manipulating
the states are desired, they might be better to be added somewhere else from the Policies
representing states.
2) The suggestion of using more fields as keys to guarantee privilege uniqueness is really
to guarantee the self-consistence of the "states" of the security system. Otherwise either
chaos would arise over time or some extra conflict resolution mechanism would need to be introduced.
This is not a novel idea. Note that, for instance, FS ACLs are keyed on the (user/group, disk
entry) pair; while the SQL privileges are keyed on a triplet of (user/role, object, privilege
type(insert, select, update, ...)).
3) The "policy tagging" I referred last time is really not a new "policy type" I introduced,
but just my realisation of how the policy can be viewed conceptually, even on the basis of
the current Ranger codes.
4) An observation is that one challenge is to bridge the gaps among different privilege systems
in a least intrusive way. Notably HDFS and Hive have some striking differences of their privilege
models; they also share many common features. If Ranger can bridge the gaps between HDFS and
Hive further, for which it has already done great I believe, it would become even more attractive.

The changes we could do, as I can perceive now, are:

1) To the minimum, add the sanity check to the policy items per policy. That is, to add uniqueness
check beyond just the check on "resource". This is probably a must; otherwise, I am afraid,
chaos might reign in the future. Note that this will probably require disparate sanity checks
for different service types, particularly for HDFS and Hive, which is seemingly absent now.
2) Next, a "DENY" action, not a policy, is introduced to facilitate easy removals of granted
privileges. Different derivatives of DENY such as DENY...EXCLUDE are optional.
3) Further closing/messaging of the remaining gaps among various privilege models may be introduced.
New concepts such as "default policies" might be introduced.   And further disparate policy
evaluation might be needed as well.
4) Policy versioning may be introduced to support more advanced auditing/analysis.

3) and 4)  probably are long term goals, and of course are subject to future discussions.

We are very interested in Ranger. Once the scopes are finalised and approved by you, we will
definitely help in implementation.  Thanks.

> 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