[Security Solution] User with Security: Read privileges can install and upgrade prebuilt rules via UI

[banderror]

🚨🚨🚨 This is a blocker for the 8.9.0 release 🚨🚨🚨

Summary

A user who has Security: Read privileges + other privileges required for Detections (docs) is able to install and upgrade prebuilt rules from the UI.

Expected behavior:

• User should not be able to do it at least from the UI (we can add privilege checks in UI and API in two different PRs, it'd be more important to hot-fix this in the UI at this point).
• All the [Install*] and [Update*] buttons should be disabled.
• The Add Elastic rules button should be disabled (both the 2 buttons, actually).
• The Rule Updates tab should be disabled.
• A tooltip should be added to each disabled element with an explanation of why it is disabled.

Screenshots

User role

Rule installation

Rule upgrade

[xcrzx]

Privilege checks on the API level have been removed as they prevent a properly configured role from installing or updating detection rules. See #161641

[xcrzx]

@banderror Since it turned out that users with read-only privileges couldn't install or upgrade prebuilt detection rules, it seems appropriate to downgrade the severity of this issue from a critical release blocker. Though an enabled install button in the UI leading to a 403 error upon clicking is not ideal for UX, but it is still pretty minor.

[banderror]

@xcrzx This role allows a Security readonly user to bypass all the checks and successfully install or upgrade prebuilt rules via the API:

{
  "_test": {
    "cluster": [],
    "indices": [
      {
        "names": [
          "filebeat-*",
          "logs-*",
          "metrics-*",
          "packetbeat-*"
        ],
        "privileges": [
          "read",
          "view_index_metadata"
        ],
        "field_security": {
          "grant": [
            "*"
          ],
          "except": []
        },
        "allow_restricted_indices": false
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_siem.read",
          "feature_savedObjectsManagement.all"
        ],
        "resources": [
          "*"
        ]
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
  }
}

We should prioritize fixing it in 8.10 for these two endpoints, as well as add appropriate RBAC checks to our other endpoints like CRUD and bulk actions. I'll create a separate ticket for that (https://github.com/elastic/security-team/issues/7114).

Let's keep this ticket with the current labels and close it when QA have verified the fix for the UI.

[jpdjere]

@banderror

After syncing with @xcrzx, I retried the POST /internal/detection_engine/prebuilt_rules/installation/_perform with a user with the configuration pasted above:

{
  "test-g": {
    "cluster": [],
    "indices": [
      {
        "names": [
          "filebeat-*",
          "logs-*",
          "metrics-*",
          "packetbeat-*"
        ],
        "privileges": [
          "read",
          "view_index_metadata"
        ],
        "field_security": {
          "grant": [
            "*"
          ],
          "except": []
        },
        "allow_restricted_indices": false
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_siem.read",
          "feature_savedObjectsManagement.all"
        ],
        "resources": [
          "*"
        ]
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
  }
}

And got the expected result:

{
    "summary": {
        "total": 3,
        "succeeded": 0,
        "skipped": 0,
        "failed": 3
    },
    "results": {
        "created": [],
        "skipped": []
    },
    "errors": [
        {
            "message": "Unauthorized to create a \"siem.mlRule\" rule for \"siem\"",
            "rules": [
                {
                    "rule_id": "1781d055-5c66-4adf-9d82-fc0fa58449c8",
                    "name": "Unusual Windows User Privilege Elevation Activity"
                }
            ]
        },
        {
            "message": "Unauthorized to create a \"siem.eqlRule\" rule for \"siem\"",
            "rules": [
                {
                    "rule_id": "15dacaa0-5b90-466b-acab-63435a59701a",
                    "name": "Virtual Private Network Connection Attempt"
                }
            ]
        },
        {
            "message": "Unauthorized to create a \"siem.queryRule\" rule for \"siem\"",
            "rules": [
                {
                    "rule_id": "9a1a2dae-0b5f-4c3d-8305-a268d404c306",
                    "name": "Endpoint Security"
                }
            ]
        }
    ]
}

I get the same type of unauthorized result for upgrading rules.

I think we might have mixed up the users or roles we were using when we tried while syncing this morning. The behaviour is as expected: a user with a role with feature_siem.read cannot install or upgrade rules, even with feature_savedObjectsManagement.all.

That given the case, I think this is enough to close this ticket and https://github.com/elastic/security-team/issues/7114

One upgrade that can be done here, as we discussed with @xcrzx, is that the validation for privilege is done at the Rules Client level, which means that the check is done for every rule that is attempted to be installed or updated. We can move that check to our endpoint handler level to have a cleaner check and improve performance. I created this tech debt ticket for that: #161772

[vgomez-el]

Fix for the UI has been verified, so I will close the issue and label it as validated