Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate field permissions when creating a role #48108

Closed

Conversation

bizybot
Copy link
Contributor

@bizybot bizybot commented Oct 16, 2019

When creating a role, we do not check if the exceptions for
the field permissions are a subset of granted fields. If such
a role is assigned to a user then that user's authentication fails
for this reason.

We added a check to validate role query in #46275 and on the same lines,
this commit adds check if the exceptions for the field
permissions is a subset of granted fields when parsing the
index privileges from the role descriptor.

When creating a role, we do not check if the exceptions for
the field permissions is a subset of granted fields. If such
role is assigned to a user the user authentication fails.
On the same lines we validate role query, this commit
adds check if the exceptions for the field
permissions is a subset of granted fields when parsing the
index privileges.
@bizybot bizybot added >bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v8.0.0 v7.6.0 labels Oct 16, 2019
@bizybot bizybot requested a review from jkakavas October 16, 2019 08:11
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Authorization)

@bizybot
Copy link
Contributor Author

bizybot commented Oct 16, 2019

@elasticmachine run elasticsearch-ci/2 elasticsearch-ci/packaging-sample-matrix

@bizybot
Copy link
Contributor Author

bizybot commented Oct 16, 2019

@elasticmachine run elasticsearch-ci/packaging-sample-matrix

@tvernum
Copy link
Contributor

tvernum commented Oct 17, 2019

Is this the behaviour we want? It seems wrong to me.

If I have a role with:

{ 
  "grant": [ "a*" ],
  "except": [ "*b" ]
}

then the meaning is clear - the role can see fields that start with a unless they end with b.
Now, I could write this as:

{ 
  "grant": [ "a*" ],
  "except": [ "a*b" ]
}

but why do we want to enforce that? Why isn't the solution to fix FLS to allow this?

@tvernum tvernum self-requested a review October 17, 2019 07:30
@bizybot
Copy link
Contributor Author

bizybot commented Oct 20, 2019

@tvernum Thank you for your comment.

Is this the behaviour we want? It seems wrong to me.

Right now this is what the behavior is, we enforce this in the FieldPermissions, I have merely reflected the validation during role creation so it does not fail during authentication for a different reason. This change is similar to the role query validation that we added when creating a role.
See FieldPermissions where the existing check is: https://github.com/elastic/elasticsearch/blob/f9227da5b9da74d3e6e214e5383a6cd426fcf81e/x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/FieldPermissions.java#L145..L148

I hope this is okay.

@tvernum
Copy link
Contributor

tvernum commented Oct 20, 2019

Right now this is what the behavior is,

And my question is, is pushing the validation up the right fix, or is it better to change the validation to accept this?
Each time we fix something we have choices about what that fix should look like, I'm just proposing that we evaluation those choices before going in 1 particular direction.

@tvernum
Copy link
Contributor

tvernum commented Oct 20, 2019

To be clear, my question is a genuine one. I'm curious as to whether, on balance people think this validation is good because leniency is dangerous and should be avoided, or bad because it's placing the burden on users to solve something that computers can do.

I can see an argument for "it should be strict and leave no room for ambiguity" or for "it should accept any values that make sense", I'd like us to take a moment to weigh up those arguments.

@tvernum
Copy link
Contributor

tvernum commented Oct 30, 2019

I spoke to @bizybot offline. I'm happy to proceed with this in its current form.

throw new ElasticsearchParseException("failed to parse indices privileges for role [{}]. [{}] field values [{}] must be a " +
"subset of [{}] field values [{}]", roleName, Fields.EXCEPT_FIELDS, Strings.arrayToCommaDelimitedString(deniedFields),
Fields.GRANT_FIELDS, Strings.arrayToCommaDelimitedString(grantedFields));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we find a way to unify (some of) this with what's already in FieldPermissions. It doesn't seem right to have to checks for the same requirement implemented separately.

@tvernum
Copy link
Contributor

tvernum commented Dec 16, 2019

Replaced by #50212

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants