[Security Solution] Prevent superuser access PLI gated APIs#176165
[Security Solution] Prevent superuser access PLI gated APIs#176165semd merged 19 commits intoelastic:mainfrom
Conversation
|
/ci |
|
@elasticmachine merge upstream |
|
/ci |
x-pack/plugins/security_solution/server/endpoint/endpoint_app_context_services.ts
Outdated
Show resolved
Hide resolved
|
/ci |
|
/ci |
x-pack/plugins/security_solution/server/lib/app_features_service/app_features_service.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/server/lib/app_features_service/app_features_service.ts
Outdated
Show resolved
Hide resolved
azasypkin
left a comment
There was a problem hiding this comment.
Security-wise, the change looks good to me, thanks. I still think that re-using access: tags for feature checks adds additional risk (even though it's not planned, the Security plugin can modify the relationship between this route tag and privilege actions in the future) and a fair amount of complexity that we could potentially avoid if we could rely solely on securitySolutionAppFeature: tags for that purpose. However, if this approach brings significant value to you, I believe it's tolerable.
|
@elasticmachine merge upstream |
|
/ci |
|
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
Pinging @elastic/security-threat-hunting-explore (Team:Threat Hunting:Explore) |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
paul-tavares
left a comment
There was a problem hiding this comment.
Thank you for all the changes - looks good 👍
|
@elasticmachine merge upstream |
|
merge conflict between base and head |
hop-dev
left a comment
There was a problem hiding this comment.
Thank for this, and the thorough entity analytics tests! 🚀
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @semd |
…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>
…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>
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
superuserrole, even if the privilege has never been registered (more context here), 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
apiandui) actions registered.access:tag control has been extended to check actions against AppFeatures for securitySolution prefixed actions.securitySolutionAppFeature:route tag control for non-RBAC product feature checks. (This is not being used yet, but it will be needed)Behavior change