[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975102#comment-14975102
]
Yan commented on RANGER-606:
----------------------------
Regarding the discussion topic, I think there are a couple of issues here.
The first is the usability. Specifically users/admins probably want to have a
security system that is easy to manage, test, verify, and, if needed, modify
with minimal impacts. For this, a clear-cut semantics with immediate effect
would be ideal if possible, which implicitly means minimum consequence
ambiguities and conflicts.
The current Ranger, due to lack of DENY, may get into a difficult-to-ascertain,
negative state. That is, e.g., if an admin wants to deny access to a user, he
may have to discover all policies that allow this user in, edit them to remove
him from the access path, test the system and go to the next iteration if more
allowing policies still exist. In addition to the efforts, after he finally
accomplishes his goal, a lot of existing, well-verified policies may have been
altered, risking of compromising other parts of the system that should have not
been touched. In the history of security system evolution, the policy system
may get very complex, making the jobs ever harder over time.
One use case is as follows. Joe initially was granted access to finance data
set. One day later, a policy was put in place which, in addition to other
items, also allows Joe to access sales data, or even to the same finance data
to make sure or to be consistent and integral with other parts of the policy.
Over time, the policy system has been evolving and involving more and more
users, groups and resources. Finally, a decision is made to revoke the
privilege to the finance data set from Joe. All these relevant policies have
to be examined and modified to remove Joe from the access path to Finance, and
eventually verified after the changes are done.
On the other hand, with the proposed DENY functionality giving priority to deny
over allow, Ranger may get into a difficult-to-ascertain positive state when
allow, or re-allow depending upon a “default policy” if any, a user access,
leading to a situation similar to that of NO DENY above.
I believe it makes a point that time ordering be honored. This is because the
events along the timeline forms a natural chain of causality that can be used
to resolve most, if not all, conflicts. For instance, during a trial-and-err
phase, an admin may do “allow/deny” in an arbitrarily number of steps
intermixed with other ops over time. The final state should be kept clearly and
honored as such immediately after each action.
In summary, probably both time-ordering and DENY in policy evaluation are to be
desired. Time-ordering is utilized to resolve privilege conflicts if any;
absence of time-ordering introduces unnecessary ambiguity and loses causality.
DENY is to provide a clear functionality to deny a privilege to a user/group;
absence of DENY makes user management pretty much a one-way traffic.
Note that the above points only deal with the semantics and functionality.
Performance and implementation considerations can be secondary and, I believe,
are manageable.
Also note that, there may still remain ambiguities in evaluation. For one,
users may belong to different groups/roles that have conflicting privileges to
a resource or a resource hierarchy. For this, solutions may be to mimic or even
delegate to the component’s “native” policy. Options of “Permissive” or
“Prohibitive” will come in this regard. Due to this, the argument for assurance
of “immediate state” may get compromised to a degree, since groupings need to
be checked as well to make sure a denial, or allowance depending the choice
between “permissive” and “prohibitive”, to a user. But that is probably as best
as we can achieve. And many systems support this semantics. In reality a user
may belong to one or just a few groups; while he might have long traces in many
policies over time.
Another potential ambiguity point is within a policy where conflicting
privileges are present, if not just for pathological purpose. How to resolve
this type of ambiguity is an open question.
In short, time-ordering is to work as the first level conflict resolution;
while the “permissive/prohibitive” is used as the second level conflict
resolution in the scenarios of hierarchical resources and hierarchical security
entities.
The second issue is the potentially disparate privilege models between
different components. For instance, SQL-like components may have different
authorization models regarding access to hierarchical resources from those of
FS-like components. A privilege to access a SQL table means a privilege to
access the table’s columns, indices, partitions, …, etc.; while a privilege to
a parent directory in HDFS does not mean a privilege to its children as well.
To have a universal privilege model would mean discrepancies of the privileges
with the native privilege models of some components, which could make migration
from the native security systems to Ranger harder and less acceptable.
Sorry for being late to join in this interesting discussion. I am still new to
Ranger, a very nice and promising project. I expect that past
lessons/patterns/idioms might be borrowed here.
> 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)
