| 2018-01-02 22:11:09 |
Matt Riedemann |
bug |
|
|
added bug |
| 2018-01-03 00:34:39 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2018-01-03 00:34:47 |
Tristan Cacqueray |
ossa: status |
New |
Incomplete |
|
| 2018-01-03 00:35:07 |
Tristan Cacqueray |
description |
The Cinder API shows attached attachments with volume details, and it includes the attached_host information for the attachments, if present, regardless of whether or not an admin token is being used:
https://github.com/openstack/cinder/blob/a95c9e5668f6a7596e0198cca2b6b7fef20ab3e9/cinder/api/v2/views/volumes.py#L126
This means a non-admin can see compute host details when a volume is attached to their instance.
This is easily recreatable in devstack:
1. Show that I'm the demo user (can't perform admin things like service-list):
stack@queens:~/devstack$ nova service-list
ERROR (Forbidden): Policy doesn't allow os_compute_api:os-services to be performed. (HTTP 403) (Request-ID: req-9e4c01ef-6bf4-41af-9768-26936f137640)
2. Create a server and a volume and attach the volume to the server:
stack@queens:~/devstack$ nova volume-attach test-server1 373c2a29-f6e7-4931-adda-6b87a193e9f9
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdb |
| id | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
| serverId | 43bc2379-86d5-49b2-a87c-5351e19ca69c |
| volumeId | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
+----------+--------------------------------------+
stack@queens:~/devstack$ openstack volume list
+--------------------------------------+------------------+--------+------+---------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+--------+------+---------------------------------------+
| 373c2a29-f6e7-4931-adda-6b87a193e9f9 | test-vol1 | in-use | 1 | Attached to test-server1 on /dev/vdb |
3. Show the volume details to see the attachment and the attached_host:
stack@queens:~/devstack$ openstack volume show test-vol1
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'43bc2379-86d5-49b2-a87c-5351e19ca69c', u'attachment_id': u'95dbfdd8-a615-4c66-a32a-79dc0dfd344e', u'attached_at': u'2018-01-02T21:37:57.000000', u'host_name': u'queens', u'volume_id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9', u'device': u'/dev/vdb', u'id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9'}] |
You can see that the host_name is in the response and the value is "queens" which is the compute hostname on this single-node install:
stack@queens:~/devstack$ sudo hostname
queens
This is using LVM by default with devstack. I tried the same thing against vexxhost and host_name came back as None, so it might be backend-specific (vexxhost is using Rbd).
This is the vexxhost output for the same scenario:
(vexxhost) user@ubuntu:~$ openstack volume show test-vol1
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'd1643bfb-1701-4adc-9980-c2553203d1f8', u'attachment_id': u'3e14b74b-7ee3-4fd8-9b8d-7a86be17cff9', u'attached_at': u'2018-01-02T21:48:32.000000', u'host_name': None, u'volume_id': u'588f0fdf-1531-44e7-8d92-16d4150c3634', u'device': u'/dev/vdb', u'id': u'588f0fdf-1531-44e7-8d92-16d4150c3634'}] |
--
This has been around since Havana: https://review.openstack.org/#/c/34125/
This is significant because the default compute API policy is to not show the compute host/node information for a server instance for non-admin users, but with this exposure in the Cinder API, non-admin users can get around that restriction (potentially - again, it seems to depend on volume backend) to see the compute host on which the volume is attached. |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
The Cinder API shows attached attachments with volume details, and it includes the attached_host information for the attachments, if present, regardless of whether or not an admin token is being used:
https://github.com/openstack/cinder/blob/a95c9e5668f6a7596e0198cca2b6b7fef20ab3e9/cinder/api/v2/views/volumes.py#L126
This means a non-admin can see compute host details when a volume is attached to their instance.
This is easily recreatable in devstack:
1. Show that I'm the demo user (can't perform admin things like service-list):
stack@queens:~/devstack$ nova service-list
ERROR (Forbidden): Policy doesn't allow os_compute_api:os-services to be performed. (HTTP 403) (Request-ID: req-9e4c01ef-6bf4-41af-9768-26936f137640)
2. Create a server and a volume and attach the volume to the server:
stack@queens:~/devstack$ nova volume-attach test-server1 373c2a29-f6e7-4931-adda-6b87a193e9f9
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdb |
| id | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
| serverId | 43bc2379-86d5-49b2-a87c-5351e19ca69c |
| volumeId | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
+----------+--------------------------------------+
stack@queens:~/devstack$ openstack volume list
+--------------------------------------+------------------+--------+------+---------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+--------+------+---------------------------------------+
| 373c2a29-f6e7-4931-adda-6b87a193e9f9 | test-vol1 | in-use | 1 | Attached to test-server1 on /dev/vdb |
3. Show the volume details to see the attachment and the attached_host:
stack@queens:~/devstack$ openstack volume show test-vol1
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'43bc2379-86d5-49b2-a87c-5351e19ca69c', u'attachment_id': u'95dbfdd8-a615-4c66-a32a-79dc0dfd344e', u'attached_at': u'2018-01-02T21:37:57.000000', u'host_name': u'queens', u'volume_id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9', u'device': u'/dev/vdb', u'id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9'}] |
You can see that the host_name is in the response and the value is "queens" which is the compute hostname on this single-node install:
stack@queens:~/devstack$ sudo hostname
queens
This is using LVM by default with devstack. I tried the same thing against vexxhost and host_name came back as None, so it might be backend-specific (vexxhost is using Rbd).
This is the vexxhost output for the same scenario:
(vexxhost) user@ubuntu:~$ openstack volume show test-vol1
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'd1643bfb-1701-4adc-9980-c2553203d1f8', u'attachment_id': u'3e14b74b-7ee3-4fd8-9b8d-7a86be17cff9', u'attached_at': u'2018-01-02T21:48:32.000000', u'host_name': None, u'volume_id': u'588f0fdf-1531-44e7-8d92-16d4150c3634', u'device': u'/dev/vdb', u'id': u'588f0fdf-1531-44e7-8d92-16d4150c3634'}] |
--
This has been around since Havana: https://review.openstack.org/#/c/34125/
This is significant because the default compute API policy is to not show the compute host/node information for a server instance for non-admin users, but with this exposure in the Cinder API, non-admin users can get around that restriction (potentially - again, it seems to depend on volume backend) to see the compute host on which the volume is attached. |
|
| 2018-01-03 00:40:11 |
Tristan Cacqueray |
bug |
|
|
added subscriber Cinder Core security contacts |
| 2018-01-04 15:16:22 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2018-01-04 15:16:37 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
| 2019-11-14 20:30:03 |
Matt Riedemann |
cinder: status |
New |
Triaged |
|
| 2020-02-27 23:43:02 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
--
The Cinder API shows attached attachments with volume details, and it includes the attached_host information for the attachments, if present, regardless of whether or not an admin token is being used:
https://github.com/openstack/cinder/blob/a95c9e5668f6a7596e0198cca2b6b7fef20ab3e9/cinder/api/v2/views/volumes.py#L126
This means a non-admin can see compute host details when a volume is attached to their instance.
This is easily recreatable in devstack:
1. Show that I'm the demo user (can't perform admin things like service-list):
stack@queens:~/devstack$ nova service-list
ERROR (Forbidden): Policy doesn't allow os_compute_api:os-services to be performed. (HTTP 403) (Request-ID: req-9e4c01ef-6bf4-41af-9768-26936f137640)
2. Create a server and a volume and attach the volume to the server:
stack@queens:~/devstack$ nova volume-attach test-server1 373c2a29-f6e7-4931-adda-6b87a193e9f9
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdb |
| id | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
| serverId | 43bc2379-86d5-49b2-a87c-5351e19ca69c |
| volumeId | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
+----------+--------------------------------------+
stack@queens:~/devstack$ openstack volume list
+--------------------------------------+------------------+--------+------+---------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+--------+------+---------------------------------------+
| 373c2a29-f6e7-4931-adda-6b87a193e9f9 | test-vol1 | in-use | 1 | Attached to test-server1 on /dev/vdb |
3. Show the volume details to see the attachment and the attached_host:
stack@queens:~/devstack$ openstack volume show test-vol1
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'43bc2379-86d5-49b2-a87c-5351e19ca69c', u'attachment_id': u'95dbfdd8-a615-4c66-a32a-79dc0dfd344e', u'attached_at': u'2018-01-02T21:37:57.000000', u'host_name': u'queens', u'volume_id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9', u'device': u'/dev/vdb', u'id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9'}] |
You can see that the host_name is in the response and the value is "queens" which is the compute hostname on this single-node install:
stack@queens:~/devstack$ sudo hostname
queens
This is using LVM by default with devstack. I tried the same thing against vexxhost and host_name came back as None, so it might be backend-specific (vexxhost is using Rbd).
This is the vexxhost output for the same scenario:
(vexxhost) user@ubuntu:~$ openstack volume show test-vol1
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'd1643bfb-1701-4adc-9980-c2553203d1f8', u'attachment_id': u'3e14b74b-7ee3-4fd8-9b8d-7a86be17cff9', u'attached_at': u'2018-01-02T21:48:32.000000', u'host_name': None, u'volume_id': u'588f0fdf-1531-44e7-8d92-16d4150c3634', u'device': u'/dev/vdb', u'id': u'588f0fdf-1531-44e7-8d92-16d4150c3634'}] |
--
This has been around since Havana: https://review.openstack.org/#/c/34125/
This is significant because the default compute API policy is to not show the compute host/node information for a server instance for non-admin users, but with this exposure in the Cinder API, non-admin users can get around that restriction (potentially - again, it seems to depend on volume backend) to see the compute host on which the volume is attached. |
The Cinder API shows attached attachments with volume details, and it includes the attached_host information for the attachments, if present, regardless of whether or not an admin token is being used:
https://github.com/openstack/cinder/blob/a95c9e5668f6a7596e0198cca2b6b7fef20ab3e9/cinder/api/v2/views/volumes.py#L126
This means a non-admin can see compute host details when a volume is attached to their instance.
This is easily recreatable in devstack:
1. Show that I'm the demo user (can't perform admin things like service-list):
stack@queens:~/devstack$ nova service-list
ERROR (Forbidden): Policy doesn't allow os_compute_api:os-services to be performed. (HTTP 403) (Request-ID: req-9e4c01ef-6bf4-41af-9768-26936f137640)
2. Create a server and a volume and attach the volume to the server:
stack@queens:~/devstack$ nova volume-attach test-server1 373c2a29-f6e7-4931-adda-6b87a193e9f9
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdb |
| id | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
| serverId | 43bc2379-86d5-49b2-a87c-5351e19ca69c |
| volumeId | 373c2a29-f6e7-4931-adda-6b87a193e9f9 |
+----------+--------------------------------------+
stack@queens:~/devstack$ openstack volume list
+--------------------------------------+------------------+--------+------+---------------------------------------+
| ID | Name | Status | Size | Attached to |
+--------------------------------------+------------------+--------+------+---------------------------------------+
| 373c2a29-f6e7-4931-adda-6b87a193e9f9 | test-vol1 | in-use | 1 | Attached to test-server1 on /dev/vdb |
3. Show the volume details to see the attachment and the attached_host:
stack@queens:~/devstack$ openstack volume show test-vol1
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'43bc2379-86d5-49b2-a87c-5351e19ca69c', u'attachment_id': u'95dbfdd8-a615-4c66-a32a-79dc0dfd344e', u'attached_at': u'2018-01-02T21:37:57.000000', u'host_name': u'queens', u'volume_id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9', u'device': u'/dev/vdb', u'id': u'373c2a29-f6e7-4931-adda-6b87a193e9f9'}] |
You can see that the host_name is in the response and the value is "queens" which is the compute hostname on this single-node install:
stack@queens:~/devstack$ sudo hostname
queens
This is using LVM by default with devstack. I tried the same thing against vexxhost and host_name came back as None, so it might be backend-specific (vexxhost is using Rbd).
This is the vexxhost output for the same scenario:
(vexxhost) user@ubuntu:~$ openstack volume show test-vol1
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attachments | [{u'server_id': u'd1643bfb-1701-4adc-9980-c2553203d1f8', u'attachment_id': u'3e14b74b-7ee3-4fd8-9b8d-7a86be17cff9', u'attached_at': u'2018-01-02T21:48:32.000000', u'host_name': None, u'volume_id': u'588f0fdf-1531-44e7-8d92-16d4150c3634', u'device': u'/dev/vdb', u'id': u'588f0fdf-1531-44e7-8d92-16d4150c3634'}] |
--
This has been around since Havana: https://review.openstack.org/#/c/34125/
This is significant because the default compute API policy is to not show the compute host/node information for a server instance for non-admin users, but with this exposure in the Cinder API, non-admin users can get around that restriction (potentially - again, it seems to depend on volume backend) to see the compute host on which the volume is attached. |
|
| 2020-03-16 13:33:06 |
OpenStack Infra |
cinder: status |
Triaged |
In Progress |
|
| 2020-03-16 13:33:06 |
OpenStack Infra |
cinder: assignee |
|
Rajat Dhasmana (whoami-rajat) |
|
| 2020-05-21 11:22:57 |
OpenStack Infra |
cinder: status |
In Progress |
Fix Released |
|
