Add get-user-privileges API #33928

tvernum · 2018-09-21T02:10:26Z

The get-user-privileges API (_xpack/security/user/_privileges) returns
the current user's effective privileges in a role-like structure.

Because the effective privileges are the result of merging potentially
multiple roles, the resulting structure has a few differences to the
standard role JSON - some fields that are single values in roles, are
multivariate (arrays) in this API.

It is only possible to return the current user's privileges, but the
es-security-runas-user header can be used to load another user as the
current effective user.

Resolves: #32777

This API is intended as a companion to the _has_privileges API. It returns the list of privileges that are held by the current user. This information is difficult to reason about, and consumers should avoid making direct security decisions based solely on this data. For example, each of the following index privileges (as well as many more) would grant a user access to index a new document into the "metrics-2018-08-30" index, but clients should not try and deduce that information from this API. - "all" on "*" - "all" on "metrics-*" - "write" on "metrics-2018-*" - "write" on "metrics-2018-08-30" Rather, if a client wished to know if a user had "index" access to _any_ index, it would be possible to use this API to determine whether the user has any index privileges, and on which index patterns, and then feed those index patterns into _has_privileges in order to determine whether the "index" privilege had been granted. The result JSON is modelled on the Role API, with a few small changes to reflect how privileges are modelled when multiple roles are merged together (multiple DLS queries, multiple FLS grants, multiple global conditions, etc).

elasticmachine · 2018-09-21T02:10:28Z

Pinging @elastic/es-security

tvernum · 2018-09-21T02:55:06Z

FYI: @kobelb

tvernum · 2018-09-21T02:55:42Z

To be handled in separate PRs:

Docs
High Level Rest Client (in progress)

tvernum · 2018-09-21T06:28:03Z

@kobelb
As part of this I found an issue that I thought I dealt with in 6.4 (but obviously didn't) regarding undefined privileges.

In 6.4, this happens:

POST _xpack/security/privilege
{ "kibana" : { "read" : { "actions": [ "data:read/*" ] } } }

{"kibana":{"read":{"created":true}}}

GET _xpack/security/privilege

{"kibana":{"read":{"application":"kibana","name":"read","actions":["data:read/*"],"metadata":{}}}}

PUT _xpack/security/role/test1
{ "applications": [ { "application": "kibana" , "privileges": ["read"], "resources":["*"] } ] }

{ "role":{"created":true}}

PUT _xpack/security/role/test2
{ "applications": [ { "application": "kibana" , "privileges": ["action:*"], "resources":["*"] } ] }

{ "role":{"created":true}}

PUT _xpack/security/role/test3
{ "applications": [ { "application": "kibana" , "privileges": ["write"], "resources":["*"] } ] }

{ "role":{"created":true}}

PUT _xpack/security/user/test1
{ "password" : "magic123", "roles" : [ "test1"] }

{"created":true}

PUT _xpack/security/user/test2
{ "password" : "magic123", "roles" : [ "test2"] }

{"created":true}

PUT _xpack/security/user/test3
{ "password" : "magic123", "roles" : [ "test3"] }

{"created":true}

for N in 1 2 3
do
  printf "\nUser: test%d :: " $N 
  curl -u test$N:magic123 \
   -XGET http://localhost:9200/_xpack/security/user/_has_privileges \
   -d '{ "application": [ { "application": "kibana", "privileges": [ "read", "write", "nothing" ], "resources": [ "*" ] } ] }' \
   -H 'Content-Type: application/json'
done

User: test1 :: {"username":"test1","has_all_requested":true,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":true,"nothing":true,"write":true}}}}
User: test2 :: {"username":"test2","has_all_requested":false,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":false,"nothing":true,"write":true}}}}
User: test3 :: {"username":"test3","has_all_requested":false,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":false,"nothing":false,"write":false}}}}

The privileges "write" and "nothing" don't exist but:

user 1 has them, because it has read which does exist, so it has something and something grants nothing.
user 2 has them, for a similar reason because it has action:*, which is something.
user 3 does not have those privilege, because it has write which doesn't exist, and nothing does not grant nothing.

The "read" privilege does exist, so only user 1 has it.

I've fixed that in this PR, so that on this branch we get

User: test1 :: {"username":"test1","has_all_requested":false,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":true,"nothing":false,"write":false}}}}
User: test2 :: {"username":"test2","has_all_requested":false,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":false,"nothing":false,"write":false}}}}
User: test3 :: {"username":"test3","has_all_requested":false,"cluster":{},"index":{},"application":{"kibana":{"*":{"read":false,"nothing":false,"write":true}}}}

which is what you expect.

no one has privileges you wouldn't expect
user 3 has write even though it isn't defined yet, because it has the same name.

I don't think that will cause you any issues, but I want to highlight it in advance.

What I've just discovered (and will fix) is that this means that superuser will return false for privileges that don't exist.
I think that's wrong, so there will be a special case that the "*" privilege will always return true, even for privileges that don't exist (since, by definition it matches everything).

kobelb · 2018-09-21T13:53:25Z

@tvernum in 6.4, we're only checking whether the user has specific actions and we aren't checking whether they have specific privileges, is it safe to assume that this same behavior that you've noticed doesn't exist in those scenarios?

tvernum · 2018-09-26T04:23:49Z

@kobelb That's correct. Checking for raw actions is not affected by this change.

kobelb · 2018-10-01T18:16:38Z

Are we still on track for this to land in 6.5? We'd ideally like to switch to this within 6.5 or else we'll be relying on a rather unperformant alternative.

tvernum · 2018-10-04T07:55:20Z

Ping @jaymode @albertzaharovits -- Any chance of a review?

albertzaharovits · 2018-10-04T15:23:15Z

...main/java/org/elasticsearch/xpack/security/rest/action/user/RestGetUserPrivilegesAction.java

+                                       XPackLicenseState licenseState) {
+        super(settings, licenseState);
+        this.securityContext = securityContext;
+        controller.registerHandler(GET, "/_xpack/security/user/{username}/_privileges", this);


Is this handler necessary? Isn't the /_xpack/security/user/_privileges enough given this is a SAME_USER_PRIVILEGE type of action?

albertzaharovits · 2018-10-04T15:34:04Z

.../main/java/org/elasticsearch/xpack/core/security/authz/permission/ApplicationPermission.java

+            .filter(e -> e.matchesPrivilege(privilege))
+            .map(e -> e.resourceNames)
+            .flatMap(Set::stream)
+            .collect(Collectors.toSet());


It looks to me that you went to great lengths to display app privileges in nicely formatted JSON.
What do you think if you also do resource-wildcard-compression here? I mean, to go through
the flatted array and eliminate resources that are a subset of another, eg user/kimchy is a subset of user/* so do not print it.
Again, I would not suggest this if you hadn't already reached up to here! Kibana will be thrilled!

This is trickier than it sounds.
The Automatons are (in some cases) already unioned, so calculating subsets is tricky.

In the example from this javadoc:

"read", [ "user/*" ] "all", [ "user/kimchy", "config/*" ]

the two resources for all are already merged into a single automaton, so there's nothing that is a pure subset of the read resource.

We can ignore the union by recompiling each of the resource names, but that would introduce Automaton compilation that we don't otherwise need.

Agreed, it would require compiling the Automaton for every element of the Set.
We can leave it as a homework for when somebody else trips on this and can't do without it.

...c/main/java/org/elasticsearch/xpack/core/security/action/user/GetUserPrivilegesResponse.java

albertzaharovits

LGTM!

jaymode

I left some minor comments. Otherwise LGTM

...rc/main/java/org/elasticsearch/xpack/core/security/action/user/GetUserPrivilegesRequest.java

jaymode · 2018-10-16T19:31:28Z

...t/java/org/elasticsearch/xpack/core/security/action/user/GetUserPrivilegesResponseTests.java

+
+import static org.hamcrest.Matchers.equalTo;
+
+public class GetUserPrivilegesResponseTests extends ESTestCase {


since this response implements equals and hashcode, can you add tests for this?

...main/java/org/elasticsearch/xpack/security/action/user/TransportGetUserPrivilegesAction.java

This API is intended as a companion to the _has_privileges API. It returns the list of privileges that are held by the current user. This information is difficult to reason about, and consumers should avoid making direct security decisions based solely on this data. For example, each of the following index privileges (as well as many more) would grant a user access to index a new document into the "metrics-2018-08-30" index, but clients should not try and deduce that information from this API. - "all" on "*" - "all" on "metrics-*" - "write" on "metrics-2018-*" - "write" on "metrics-2018-08-30" Rather, if a client wished to know if a user had "index" access to _any_ index, it would be possible to use this API to determine whether the user has any index privileges, and on which index patterns, and then feed those index patterns into _has_privileges in order to determine whether the "index" privilege had been granted. The result JSON is modelled on the Role API, with a few small changes to reflect how privileges are modelled when multiple roles are merged together (multiple DLS queries, multiple FLS grants, multiple global conditions, etc). Backport of: 9200e15, 2283a33, aeb3cda

This API is intended as a companion to the _has_privileges API. It returns the list of privileges that are held by the current user. This information is difficult to reason about, and consumers should avoid making direct security decisions based solely on this data. For example, each of the following index privileges (as well as many more) would grant a user access to index a new document into the "metrics-2018-08-30" index, but clients should not try and deduce that information from this API. - "all" on "*" - "all" on "metrics-*" - "write" on "metrics-2018-*" - "write" on "metrics-2018-08-30" Rather, if a client wished to know if a user had "index" access to _any_ index, it would be possible to use this API to determine whether the user has any index privileges, and on which index patterns, and then feed those index patterns into _has_privileges in order to determine whether the "index" privilege had been granted. The result JSON is modelled on the Role API, with a few small changes to reflect how privileges are modelled when multiple roles are merged together (multiple DLS queries, multiple FLS grants, multiple global conditions, etc).

## Summary This PR solves an issue with `superuser` (or any `*`) role and PLI (product level item) control. Elasticsearch _has_privileges_ API always returns _true_ on any privilege for `superuser` role, even if the privilege has never been registered (more context [here](elastic/elasticsearch#33928 (comment))), causing superuser to be able to access product-restricted APIs (e.g. Routes that should only be available on _complete_ tier, are also available on _essentials_ tier). ## Solution We have the registered AppFeatures configuration locally, so we can solve the problem by checking that the action privilege exists and has been registered in the AppFeatures service, before doing any call to ES _hasPrivileges_ API for RBAC. ### Changes - AppFeatures service now stores a Set with all the (`api` and `ui`) actions registered. - Endpoint authz checks the actions against AppFeatures before checking RBAC. Only for server-side. - Route `access:` tag control has been extended to check actions against AppFeatures for _securitySolution_ prefixed actions. - New `securitySolutionAppFeature:` route tag control for non-RBAC product feature checks. (This is not being used yet, but it will be needed) ### Behavior change - UI: no change, everything should keep working the same way. - API: routes associated with higher product tier features (such as endpoint or entity analytics) won't be accessible for the superuser/admin role when running on lower product tiers, like _security essentials_. --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

…176165) ## Summary This PR solves an issue with `superuser` (or any `*`) role and PLI (product level item) control. Elasticsearch _has_privileges_ API always returns _true_ on any privilege for `superuser` role, even if the privilege has never been registered (more context [here](elastic/elasticsearch#33928 (comment))), causing superuser to be able to access product-restricted APIs (e.g. Routes that should only be available on _complete_ tier, are also available on _essentials_ tier). ## Solution We have the registered AppFeatures configuration locally, so we can solve the problem by checking that the action privilege exists and has been registered in the AppFeatures service, before doing any call to ES _hasPrivileges_ API for RBAC. ### Changes - AppFeatures service now stores a Set with all the (`api` and `ui`) actions registered. - Endpoint authz checks the actions against AppFeatures before checking RBAC. Only for server-side. - Route `access:` tag control has been extended to check actions against AppFeatures for _securitySolution_ prefixed actions. - New `securitySolutionAppFeature:` route tag control for non-RBAC product feature checks. (This is not being used yet, but it will be needed) ### Behavior change - UI: no change, everything should keep working the same way. - API: routes associated with higher product tier features (such as endpoint or entity analytics) won't be accessible for the superuser/admin role when running on lower product tiers, like _security essentials_. --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

tvernum added 9 commits September 5, 2018 15:53

Fix field names in Rest output

9763ae1

Merge branch 'master' into list-privileges

b33b5cf

Add rest test for get-user-privileges

303398c

Merge branch 'master' into list-privileges

17b0656

Remove unnecessary logging

09ed19f

Add test for Transport action

4793d48

Add test cases (and fix some imports)

4307a70

Merge branch 'master' into get-user-privileges

67b9f40

tvernum added >feature review v7.0.0 :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v6.5.0 labels Sep 21, 2018

tvernum requested review from jaymode and albertzaharovits September 21, 2018 02:10

Allow superuser to have rights that don't exist

a7bfd1c

Merge branch 'master' into get-user-privileges

66e1fdb

Merge branch 'master' into get-user-privileges

2d6f673

albertzaharovits reviewed Oct 4, 2018

View reviewed changes

...c/main/java/org/elasticsearch/xpack/core/security/action/user/GetUserPrivilegesResponse.java Show resolved Hide resolved

tvernum added 5 commits October 5, 2018 15:42

Address feedback

b88e5bb

Merge branch 'master' into get-user-privileges

9b0cccb

Fix import

6406207

Fix Rest Spec/Test for URL change

20d39a6

Merge branch 'master' into get-user-privileges

638ca6e

rjernst removed the review label Oct 10, 2018

albertzaharovits approved these changes Oct 16, 2018

View reviewed changes

jaymode approved these changes Oct 16, 2018

View reviewed changes

tvernum added 3 commits October 17, 2018 12:17

Merge branch 'master' into get-user-privileges

07345da

Address additional feedback

667cc68

Fix test

987a5b2

tvernum merged commit 9200e15 into elastic:master Oct 18, 2018

tvernum added the backport pending label Oct 18, 2018

albertzaharovits mentioned this pull request Oct 19, 2018

[TEST] GetUserPrivilegesResponseTests#testSerialization failing #34631

Closed

vladimirdolzhenko mentioned this pull request Oct 20, 2018

[CI] GetUserPrivilegesResponseTests fails #34671

Closed

tvernum removed the backport pending label Oct 22, 2018

tvernum mentioned this pull request Oct 23, 2018

Rest Tests - Support for matching objects in lists #34693

Merged

tvernum mentioned this pull request Dec 10, 2018

HLRC: Implement get-user-privileges API #36292

Merged

Mpdreamz mentioned this pull request Dec 13, 2018

[meta] 6.5.0 Release elastic/elasticsearch-net#3457

Closed

colings86 added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019

n1v0lg mentioned this pull request Jan 29, 2024

Test unknown named application privileges #104863

Draft

semd mentioned this pull request Feb 5, 2024

[Security Solution] Prevent superuser access PLI gated APIs elastic/kibana#176165

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add get-user-privileges API #33928

Add get-user-privileges API #33928

tvernum commented Sep 21, 2018

elasticmachine commented Sep 21, 2018

tvernum commented Sep 21, 2018

tvernum commented Sep 21, 2018

tvernum commented Sep 21, 2018 •

edited

Loading

kobelb commented Sep 21, 2018

tvernum commented Sep 26, 2018

kobelb commented Oct 1, 2018

tvernum commented Oct 4, 2018

albertzaharovits Oct 4, 2018

jaymode Oct 5, 2018

albertzaharovits Oct 4, 2018

tvernum Oct 5, 2018

albertzaharovits Oct 16, 2018

albertzaharovits left a comment

jaymode left a comment

jaymode Oct 16, 2018


		import static org.hamcrest.Matchers.equalTo;

		public class GetUserPrivilegesResponseTests extends ESTestCase {

Add get-user-privileges API #33928

Add get-user-privileges API #33928

Conversation

tvernum commented Sep 21, 2018

elasticmachine commented Sep 21, 2018

tvernum commented Sep 21, 2018

tvernum commented Sep 21, 2018

tvernum commented Sep 21, 2018 • edited Loading

kobelb commented Sep 21, 2018

tvernum commented Sep 26, 2018

kobelb commented Oct 1, 2018

tvernum commented Oct 4, 2018

albertzaharovits Oct 4, 2018

Choose a reason for hiding this comment

jaymode Oct 5, 2018

Choose a reason for hiding this comment

albertzaharovits Oct 4, 2018

Choose a reason for hiding this comment

tvernum Oct 5, 2018

Choose a reason for hiding this comment

albertzaharovits Oct 16, 2018

Choose a reason for hiding this comment

albertzaharovits left a comment

Choose a reason for hiding this comment

jaymode left a comment

Choose a reason for hiding this comment

jaymode Oct 16, 2018

Choose a reason for hiding this comment

tvernum commented Sep 21, 2018 •

edited

Loading