cb4682fb83
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 available at - `os-detach`: Detach a volume - `os-force_detach`: Force detach a volume In this endpoint we just won't allow anything that is not coming from a service. This should not be a problem 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 |
||
|---|---|---|
| .. | ||
| source | ||