[Security Solution] [Bug] Alerts allow write actions to read-only users

[semd]

Describe the bug:

Alerts write actions are available and working for roles without write Security feature privilege.

Steps to reproduce:

1. Open an ESS (non-serverless) instance.
2. Create a role with all index and kibana privileges, except for read access to Security in the Kibana privileges.
3. Using the new role go to the Alerts page, select an alert, go to "Selected Alerts".

Current behavior:
Open, close, ack, and alert tags are all available

Expected behavior:
Open, close, ack, and alert tags should be hidden

Additional information:

Related to this issue: #169684

The fix does not check the Kibana feature privileges, which is necessary to prevent the authorization bug. The current logic is checking index privileges only, which is actually not strictly necessary, since ES itself will reject write operations to the index if the write privilege is not granted, and the error would pop up in the UI.

Screenshots:

Role definition:

Demo:

alerts_bug_readonly_privilege.mov

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[semd]

Talked with @yctercero about this, the permissions table in the the docs states that only the Read Kibana privilege is required for Security feature in order to "manage alerts".

This means that a Security read-only user is allowed to update alerts (status, tags, assignments...), it is the expected behavior. So according to the docs, this issue is not a bug.

However, I would like to understand why are we applying this special behavior here, because this criteria is inconsistent with the privilege checks we do in the rest of the Security application.

If there's no special reason I think we should consider changing that behavior to be consistent, and update the docs.

cc @paulewing

[semd]

Discussed with @paulewing.
It seems this criteria was put in place to allow Analyst users to manage alerts, but not to manage rules.

In a perfect world ✨, this behavior should be accomplished using a Kibana sub-feature for alerts (or rules) management, but since we are still not able to migrate roles due to an architectural limitation, extracting "alert management" into a new sub-feature would result in the introduction of breaking changes in the RBAC system for existing users, so the Read Kibana privilege was (miss)used instead to achieve the same behavior.

Nonetheless, the Security (Kibana Platform) team has plans to provide a way to migrate existing roles in the mid-term (issue), when this is available it would be great to revisit this topic, and add more granularity to the Security RBAC system, having sub-features for key functionalities such as alerts, timelines, rules, and so on.

closing this issue.