Do we have a realistic customer asking for exception on Deny set?
On Thu, Oct 15, 2015 at 10:32 AM, Balaji Ganesan <[email protected] > wrote: > I think we completely missed my earlier point. My question was around > whether we need to have exceptions in Deny and Allow beyond just Allow or > Deny policy items. I used the MSFT example to see if they have implemented > exceptions to Deny, which I did not find any. I am not suggesting that we > ask the users to order the policies and Ranger follow the order. > > We can open a separate thread on whether Ranger needs to use an explicit > hierarchy for policy evaluation or not. For the current discussion, I don't > see a specific use case where we would need a deny or allow exception and > not fulfilled by just allow or deny functionality. > > Let us take the use case we discussed earlier. The group "interns" got > denied,but we want to exclude one user ("Scott") from that, I am suggesting > to have the particular user ("Scott") included in the Allow section of > policy and group "interns" included in Deny section of the same policy. > Ranger should evaluate the both Allow and Deny in the same policy and > deduce that user "Scott" can access the resource while anyone else in group > "interns" is denied to access the resource. The policy creation in the UI > is much simpler than having to specify "Scott" as an exception to Deny and > then specifying "Scott" for Allow. > > On Wed, Oct 14, 2015 at 11:36 AM, Madhan Neethiraj < > [email protected]> wrote: > >> Microsoft DACL also talks about exceptions, but the model relies on the >> users to setup ACE in specific order – see below. >> >> From >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa446597(v=vs.85).aspx >> : >> >> "In most cases, you can control access to an object by using >> access-allowed ACEs; you do not need to explicitly deny access to an >> object. The exception is when an ACE allows access to a group and you want >> to deny access to a member of the group. To do this, place an access-denied >> ACE for the user in the DACL ahead of the access-allowed ACE for the group. >> Note that the order of the ACEs >> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa379298(v=vs.85).aspx> >> is >> important because the system reads the ACEs in sequence until access is >> granted or denied. The user's access-denied ACE must appear first; >> otherwise, when the system reads the group's access allowed ACE, it will >> grant access to the restricted user." >> >> This approach of relying on ordering of policy items (equivalent of ACEs >> above) can work for Ranger as well. However Microsoft DACL model evaluates >> only one DACL to determine access to an object; compare this with Ranger >> where there could be multiple policies that can be evaluated for a resource >> – for example to determine access to a finance.invoice.ssn column, Ranger >> would evaluate policies that are applicable for finance database, >> finance.invoice table and finance.invoice.ssn column. To guarantee >> consistent authorization result, that relies on proper ordering of >> allow/deny policy items in each policy, would require the policies to be >> evaluated in a specific order – either most-specific-to-most-generic >> (column policy, table policy, database policy) or most-generic-to >> most-specific. And it might be very challenging, if not impossible, to >> ensure a policy order given our support for wildcard specification – for >> example, should a policy for “/finance/*2015/*” be evaluated before a >> policy for “/finance/invoice*/*” while determining access for a file named >> “/finance/invoice2015/vendor1.txt”? >> >> I think this approach would make the policy authoring very difficult and >> confusing, in addition to being not able to support certain scenarios like >> “deny at a higher level (like for a database), even if access might be >> allowed at a lower level (for a table/column)”, “allow at a higher level, >> but deny at a lower level). The current implementation (in tag-policy >> branch of Ranger) is much less confusing and offers building blocks that >> can be used to support more usecases and can guarantee consistent results >> for a given set of policies. If we are after simplicity, the DACL model >> does not seem to be the right choice.. >> >> Thanks, >> Madhan >> >> >> From: Balaji Ganesan >> Reply-To: "[email protected]" >> Date: Wednesday, October 14, 2015 at 10:31 AM >> >> To: "[email protected]" >> Subject: Re: [DISCUSS] Policy model enhancement to support >> deny-conditions and exceptions >> >> >> My proposal is to just keep the policy to have only allow and deny >> with NO exceptions. In your use case, if we allow "finance" group and deny >> "intern" group, then anyone in intern group would not be allowed while >> everyone else in finance group will get access. If there is a person in >> intern group who needs access, then user need to be taken out of the intern >> group or we need to add only the users who specifically need to be denied. >> >> <<Users who are not comfortable with the idea of “excludes” can continue >> to use only allow and deny in the policies. Users who are comfortable with >> “excludes” can choose to use it to simplify their policy management.>> >> >> The question here is whether exceptions are really needed in the product. >> We need to keep the product simple >> Questions is what use cases can exceptions clearly solve above and beyond >> simply access grant and access deny policy line items. As an example, I am >> looking at MSFT for how they have have implemented deny-access >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa446597(v=vs.85).aspx. >> The use case MSFT is trying to solve it denying access to specific users >> who are part of the group which is provided access. I think most of the >> deny-access use cases would be for specific users, not for large sets of >> groups. >> >> >> On Tue, Oct 13, 2015 at 11:47 PM, Madhan Neethiraj < >> [email protected]> wrote: >> >>> >> For argument sakes, finance could be the higher level group and >>> intern could be a sub group in a hierarchy. There could be n number of sub >>> groups. We could provide access by adding n-1 groups to the policy. We can >>> argue whether n<10 or n>50, depending on the answer it would make sense to >>> add all groups which needs access or specify deny groups which don't need >>> access >>> >>> The groups may not fall into nice hierarchies – for example, interns >>> group might consist of users from various orgs in a company (not just from >>> finance group). In such cases, the only choice is to setup Ranger policies >>> with individual users (and not groups). >>> >>> >> My proposal is to just keep the policy to have only allow and deny >>> with NO exceptions. In your use case, if we allow "finance" group and deny >>> "intern" group, then anyone in intern group would not be allowed while >>> everyone else in finance group will get access. If there is a person in >>> intern group who needs access, then user need to be taken out of the intern >>> group or we need to add only the users who specifically need to be denied. >>> >>> Users who are not comfortable with the idea of “excludes” can continue >>> to use only allow and deny in the policies. Users who are comfortable with >>> “excludes” can choose to use it to simplify their policy management. >>> >>> Thanks, >>> Madhan >>> >>> From: Balaji Ganesan >>> Reply-To: "[email protected]" >>> Date: Tuesday, October 13, 2015 at 10:24 PM >>> >>> To: "[email protected]" >>> Subject: Re: [DISCUSS] Policy model enhancement to support >>> deny-conditions and exceptions >>> >>> <<Are you suggesting that the security admins create policies that list >>> individual users, instead of using groups? Wouldn’t that make security >>> administration more painful, in a reasonably large organization? For every >>> change in users role (or group) or an employee joining/leaving the org, all >>> security policies have to be reviewed and updated.. Many ACLs support both >>> users and groups to alleviate this issue.>> >>> For argument sakes, finance could be the higher level group and intern >>> could be a sub group in a hierarchy. There could be n number of sub groups. >>> We could provide access by adding n-1 groups to the policy. We can argue >>> whether n<10 or n>50, depending on the answer it would make sense to add >>> all groups which needs access or specify deny groups which don't need access >>> >>> My proposal is to just keep the policy to have only allow and deny with >>> NO exceptions. In your use case, if we allow "finance" group and deny >>> "intern" group, then anyone in intern group would not be allowed while >>> everyone else in finance group will get access. If there is a person in >>> intern group who needs access, then user need to be taken out of the intern >>> group or we need to add only the users who specifically need to be denied. >>> >>> On Tue, Oct 13, 2015 at 9:48 PM, Madhan Neethiraj <[email protected]> >>> wrote: >>> >>>> Balaji, >>>> >>>> >> why cannot user clearly specific users or groups that would need >>>> specific access. Why is there a need to give access to finance group as a >>>> whole when we know there is a subset of user who do not need access to the >>>> the finance database? or clearly specify users who need to be denied? >>>> Are you suggesting that the security admins create policies that list >>>> individual users, instead of using groups? Wouldn’t that make security >>>> administration more painful, in a reasonably large organization? For every >>>> change in users role (or group) or an employee joining/leaving the org, all >>>> security policies have to be reviewed and updated.. Many ACLs support both >>>> users and groups to alleviate this issue. >>>> >>>> >>>> From: Balaji Ganesan >>>> Reply-To: "[email protected]" >>>> Date: Tuesday, October 13, 2015 at 9:01 PM >>>> >>>> To: "[email protected]" >>>> Subject: Re: [DISCUSS] Policy model enhancement to support >>>> deny-conditions and exceptions >>>> >>>> Madhan, Fantastic job in putting together in the wiki. Thank you. >>>> >>>> We clearly need to show case use cases for deny exclude and allow >>>> exclude. In my opinion it is very confusing to user to construct such a >>>> policy >>>> >>>> <<Let’s say one of the users, scott who is in interns and finance >>>> groups, works on an assignment that requires select access to finance >>>> database. To enable this access, the authorization policy for the database >>>> should be updated by adding a deny-exclude, as shown below:>> >>>> In the wiki, we have created a "deny" policy for intern group and an >>>> exception for Scott. First of all, why cannot user clearly specific users >>>> or groups that would need specific access. Why is there a need to give >>>> access to finance group as a whole when we know there is a subset of user >>>> who do not need access to the the finance database? or clearly specify >>>> users who need to be denied? It is confusing to think about exceptions for >>>> deny, deny, exceptions for allow and allow. >>>> >>>> >>>> On Tue, Oct 13, 2015 at 2:43 PM, Madhan Neethiraj <[email protected]> >>>> wrote: >>>> >>>>> Bosco, >>>>> >>>>> Thanks for the review and comments. The wiki >>>>> <https://cwiki.apache.org/confluence/display/RANGER/Deny-conditions+and+excludes+in+Ranger+policies> >>>>> has been updated to address your comments. Please review. >>>>> >>>>> Thanks, >>>>> Madhan >>>>> >>>>> From: Don Bosco Durai >>>>> Reply-To: "[email protected]" >>>>> Date: Monday, October 12, 2015 at 6:20 PM >>>>> To: "[email protected]" >>>>> Subject: Re: [DISCUSS] Policy model enhancement to support >>>>> deny-conditions and exceptions >>>>> >>>>> Madhan, thanks for putting this document together. It is looking good. >>>>> >>>>> Can I make a few suggestions: >>>>> >>>>> 1. Call out each use case as separate section. E.g. 2.2.3 for >>>>> "HDFS policy that allows all finance group users to access contents of >>>>> /finance folder, but denies access to users in interns group. Users in >>>>> interns group will be denied the access even if they are part of >>>>> finance >>>>> group.” >>>>> 2. Can we also add a simple use case of global “Deny”. E.g Deny >>>>> all users from “interns” group from accessing table “Employees" >>>>> 3. The label “Exceptions”, can we make it more explicit. E.g. >>>>> “Exclude from Allow Conditions” and “Exclude from Deny Conditions” >>>>> 4. Probably one small paragraph to explain “Exceptions” will be >>>>> good. I think, this is sort of a new concept. >>>>> 5. Section 3 “Policy Evaluation”, it seems to be a flow chart. Can >>>>> we create flow chart diagram. It will be easy to understand >>>>> >>>>> Thanks again. Let me know if you need help in the documentation. >>>>> >>>>> Bosco >>>>> >>>>> >>>>> From: Madhan Neethiraj >>>>> Reply-To: <[email protected]> >>>>> Date: Monday, October 12, 2015 at 5:46 PM >>>>> To: "[email protected]" >>>>> Subject: [DISCUSS] Policy model enhancement to support >>>>> deny-conditions and exceptions >>>>> >>>>> All, >>>>> >>>>> Apache Ranger policy model enhancement to support deny-conditions and >>>>> exceptions (RANGER-606 >>>>> <https://issues.apache.org/jira/browse/RANGER-606>) is available in >>>>> tag-policy >>>>> branch <https://github.com/apache/incubator-ranger/tree/tag-policy>. >>>>> This enhancement adds the capability to explicitly deny access to >>>>> resources >>>>> based on users/groups, access-types and custom-conditions. It also >>>>> supports >>>>> allow/deny to be specified for a wider group (like employees, public, etc) >>>>> but exclude specific users/groups who might be part of the wider groups. >>>>> >>>>> An overview of the implementation, along with few examples is >>>>> available in Apache wiki page here >>>>> <https://cwiki.apache.org/confluence/display/RANGER/Deny-conditions+and+exceptions+in+Ranger+policies>. >>>>> Please review. >>>>> >>>>> Thanks, >>>>> Madhan >>>>> >>>>> >>>>> >>>> >>> >> >
