6df1839bdf
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
44 lines
2.3 KiB
YAML
44 lines
2.3 KiB
YAML
---
|
|
critical:
|
|
- |
|
|
Detaching volumes will fail if Nova is not `configured to send service
|
|
tokens <https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html>`_,
|
|
please read the upgrade section for more information. (`Bug #2004555
|
|
<https://bugs.launchpad.net/cinder/+bug/2004555>`_).
|
|
upgrade:
|
|
- |
|
|
Nova must be `configured to send service tokens
|
|
<https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html>`_
|
|
**and** cinder must be configured to recognize at least one of the roles
|
|
that the nova service user has been assigned in keystone. By default,
|
|
cinder will recognize the ``service`` role, so if the nova service user
|
|
is assigned a differently named role in your cloud, you must adjust your
|
|
cinder configuration file (``service_token_roles`` configuration option
|
|
in the ``keystone_authtoken`` section). If nova and cinder are not
|
|
configured correctly in this regard, detaching volumes will no longer
|
|
work (`Bug #2004555 <https://bugs.launchpad.net/cinder/+bug/2004555>`_).
|
|
security:
|
|
- |
|
|
As part of the fix for `Bug #2004555
|
|
<https://bugs.launchpad.net/cinder/+bug/2004555>`_, cinder now rejects
|
|
user attachment delete requests for attachments that are being used by nova
|
|
instances to ensure that no leftover devices are produced on the compute
|
|
nodes which could be used to access another project's volumes. Terminate
|
|
connection, detach, and force detach volume actions (calls that are not
|
|
usually made by users directly) are, in most cases, not allowed for users.
|
|
fixes:
|
|
- |
|
|
`Bug #2004555 <https://bugs.launchpad.net/cinder/+bug/2004555>`_: Fixed
|
|
issue where a user manually deleting an attachment, calling terminate
|
|
connection, detach, or force detach, for a volume that is still used by a
|
|
nova instance resulted in leftover devices on the compute node. These
|
|
operations will now fail when it is believed to be a problem.
|
|
issues:
|
|
- |
|
|
For security reasons (`Bug #2004555
|
|
<https://bugs.launchpad.net/cinder/+bug/2004555>`_) manually deleting an
|
|
attachment, manually doing the ``os-terminate_connection``, ``os-detach``
|
|
or ``os-force_detach`` actions will no longer be allowed in most cases
|
|
unless the request is coming from another OpenStack service on behalf of a
|
|
user.
|