From 6df1839bdf288107c600b3e53dff7593a6d4c161 Mon Sep 17 00:00:00 2001 From: Gorka Eguileor Date: Thu, 16 Feb 2023 15:57:15 +0100 Subject: Reject unsafe delete attachment calls Due to how the Linux SCSI kernel driver works there are some storage systems, such as iSCSI with shared targets, where a normal user can access other projects' volume data connected to the same compute host using the attachments REST API. This affects both single and multi-pathed connections. To prevent users from doing this, unintentionally or maliciously, cinder-api will now reject some delete attachment requests that are deemed unsafe. Cinder will process the delete attachment request normally in the following cases: - The request comes from an OpenStack service that is sending the service token that has one of the roles in `service_token_roles`. - Attachment doesn't have an instance_uuid value - The instance for the attachment doesn't exist in Nova - According to Nova the volume is not connected to the instance - Nova is not using this attachment record There are 3 operations in the actions REST API endpoint that can be used for an attack: - `os-terminate_connection`: Terminate volume attachment - `os-detach`: Detach a volume - `os-force_detach`: Force detach a volume In this endpoint we just won't allow most requests not coming from a service. The rules we apply are the same as for attachment delete explained earlier, but in this case we may not have the attachment id and be more restrictive. This should not be a problem for normal operations because: - Cinder backup doesn't use the REST API but RPC calls via RabbitMQ - Glance doesn't use this interface anymore Checking whether it's a service or not is done at the cinder-api level by checking that the service user that made the call has at least one of the roles in the `service_token_roles` configuration. These roles are retrieved from keystone by the keystone middleware using the value of the "X-Service-Token" header. If Cinder is configured with `service_token_roles_required = true` and an attacker provides non-service valid credentials the service will return a 401 error, otherwise it'll return 409 as if a normal user had made the call without the service token. Closes-Bug: #2004555 Change-Id: I612905a1bf4a1706cce913c0d8a6df7a240d599a --- api-ref/source/v3/attachments.inc | 15 +++++++ api-ref/source/v3/volumes-v3-volumes-actions.inc | 55 ++++++++++++++++++++++++ 2 files changed, 70 insertions(+) (limited to 'api-ref/source') diff --git a/api-ref/source/v3/attachments.inc b/api-ref/source/v3/attachments.inc index 87b57d609..cb3784865 100644 --- a/api-ref/source/v3/attachments.inc +++ b/api-ref/source/v3/attachments.inc @@ -41,6 +41,20 @@ Delete attachment Deletes an attachment. +For security reasons (see bug `#2004555 +`_) the Block Storage API rejects +REST API calls manually made from users with a 409 status code if there is a +Nova instance currently using the attachment, which happens when all the +following conditions are met: + +- Attachment has an instance uuid +- VM exists in Nova +- Instance has the volume attached +- Attached volume in instance is using the attachment + +Calls coming from other OpenStack services (like the Compute Service) are +always accepted. + Available starting in the 3.27 microversion. Response codes @@ -54,6 +68,7 @@ Response codes - 400 - 404 + - 409 Request diff --git a/api-ref/source/v3/volumes-v3-volumes-actions.inc b/api-ref/source/v3/volumes-v3-volumes-actions.inc index 808dcda8d..bb79e309b 100644 --- a/api-ref/source/v3/volumes-v3-volumes-actions.inc +++ b/api-ref/source/v3/volumes-v3-volumes-actions.inc @@ -337,6 +337,21 @@ Preconditions - Volume status must be ``in-use``. +For security reasons (see bug `#2004555 +`_), regardless of the policy +defaults, the Block Storage API rejects REST API calls manually made from +users with a 409 status code if completing the request could pose a risk, which +happens if all of these happen: + +- The request comes from a user +- There's an instance uuid in provided attachment or in the volume's attachment +- VM exists in Nova +- Instance has the volume attached +- Attached volume in instance is using the attachment + +Calls coming from other OpenStack services (like the Compute Service) are +always accepted. + Response codes -------------- @@ -344,6 +359,9 @@ Response codes - 202 +.. rest_status_code:: error ../status.yaml + + - 409 Request ------- @@ -415,6 +433,21 @@ perform this operation. Cloud providers can change these permissions through the ``volume_extension:volume_admin_actions:force_detach`` rule in the policy configuration file. +For security reasons (see bug `#2004555 +`_), regardless of the policy +defaults, the Block Storage API rejects REST API calls manually made from +users with a 409 status code if completing the request could pose a risk, which +happens if all of these happen: + +- The request comes from a user +- There's an instance uuid in provided attachment or in the volume's attachment +- VM exists in Nova +- Instance has the volume attached +- Attached volume in instance is using the attachment + +Calls coming from other OpenStack services (like the Compute Service) are +always accepted. + Response codes -------------- @@ -422,6 +455,9 @@ Response codes - 202 +.. rest_status_code:: error ../status.yaml + + - 409 Request ------- @@ -883,6 +919,22 @@ Preconditions - Volume status must be ``in-use``. +For security reasons (see bug `#2004555 +`_), regardless of the policy +defaults, the Block Storage API rejects REST API calls manually made from +users with a 409 status code if completing the request could pose a risk, which +happens if all of these happen: + +- The request comes from a user +- There's an instance uuid in the volume's attachment +- VM exists in Nova +- Instance has the volume attached +- Attached volume in instance is using the attachment + +Calls coming from other OpenStack services (like the Compute Service) are +always accepted. + + Response codes -------------- @@ -890,6 +942,9 @@ Response codes - 202 +.. rest_status_code:: error ../status.yaml + + - 409 Request ------- -- cgit v1.2.1