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
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
(cherry picked from commit 6df1839bdf288107c600b3e53dff7593a6d4c161)
Conflicts: cinder/exception.py
(cherry picked from commit dd6010a9f7bf8cbe0189992f0848515321781747)
(cherry picked from commit cb4682fb836912225c5da1536108a0d05fd5c46e)
Conflicts: cinder/exception.py
(cherry picked from commit a66f4afa22fc5a0a85d5224a6b63dd766fef47b1)
Conflicts: cinder/compute/nova.py cinder/tests/unit/attachments/test_attachments_api.py cinder/volume/api.py
Reviewed: https:/ /review. opendev. org/c/openstack /cinder/ +/882839 /opendev. org/openstack/ cinder/ commit/ 68fdc323369943f 494541a3510e712 90b091359f
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit 68fdc323369943f 494541a3510e712 90b091359f
Author: Gorka Eguileor <email address hidden>
Date: Thu Feb 16 15:57:15 2023 +0100
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 token_roles` .
service token that has one of the roles in `service_
- 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
Checking whether it's a service or not is done at the cinder-api level token_roles` configuration. These roles are
by checking that the service user that made the call has at least one of
the roles in the `service_
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 06cce913c0d8a6d f7a240d599a 7c600b3e53dff75 93a6d4c161)
cinder/ exception. py e0189992f084851 5321781747) 25c5da1536108a0 d05fd5c46e)
cinder/ exception. py a85d5224a6b63dd 766fef47b1)
cinder/ compute/ nova.py
cinder/ tests/unit/ attachments/ test_attachment s_api.py
cinder/ volume/ api.py
Change-Id: I612905a1bf4a17
(cherry picked from commit 6df1839bdf28810
Conflicts:
(cherry picked from commit dd6010a9f7bf8cb
(cherry picked from commit cb4682fb8369122
Conflicts:
(cherry picked from commit a66f4afa22fc5a0
Conflicts: