Open Stack

** Description changed:

- 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 following information is discoverable for non-admin users of neutron despite the policy:
  * the segmentation type and id of all vlan based networks
  * the segmentation type of all non-vlan based networks
  
  Reproduction:
  
  configuration)
  
  [[local|localrc]]
  enable_plugin neutron ...
  enable_service q-trunk
  
  versions)
  
  devstack b79531a9f96736225a8991052a0be5767c217377
  neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c
  
  1) for vlan networks
  
  source openrc admin demo
  openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
  openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101
  
  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
  
  # demo user has no right to see segmentation type and id of vlan provider net
  openstack network show net1
  # but both the type and id are available in the subport list
  openstack network subport list --trunk trunk0
  
  2) for other network types
  
  source openrc admin demo
  openstack network create net0
  openstack network create net1
  
  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  # the type of net1 comes back in the error message (in my environment 'vxlan')
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit
  
  While according to the default policy this information should be admin-only. See around here:
  https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45
  
  This behavior was introduced in response to this rfe:
  https://bugs.launchpad.net/neutron/+bug/1648129
  
  Actually sharing this information is the point of the rfe.
  
  IIRC the concern about the information leak was even raised during a
  review, but it seems it went unaddressed. (Yep, I found the comment
  again: https://review.openstack.org/436756 comment at 03-07 21:12)
  
  I'm not sure if the segmentation details should be considered sensitive
  information or not. But the current behavior (admin-only here, not
  admin-only there) is clearly inconsistent.
  
  We could probably solve this by just synchronizing the default policies
  of provider network get operation and subport segmentation detail
  inheritance.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1704398

Title:
  Inheriting trunk subport segmentation details leaks information

Status in neutron:
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The following information is discoverable for non-admin users of neutron despite the policy:
  * the segmentation type and id of all vlan based networks
  * the segmentation type of all non-vlan based networks

  Reproduction:

  configuration)

  [[local|localrc]]
  enable_plugin neutron ...
  enable_service q-trunk

  versions)

  devstack b79531a9f96736225a8991052a0be5767c217377
  neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c

  1) for vlan networks

  source openrc admin demo
  openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100
  openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101

  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit

  # demo user has no right to see segmentation type and id of vlan provider net
  openstack network show net1
  # but both the type and id are available in the subport list
  openstack network subport list --trunk trunk0

  2) for other network types

  source openrc admin demo
  openstack network create net0
  openstack network create net1

  source openrc demo demo
  openstack port create port0 --network net0
  openstack port create port1 --network net1
  openstack network trunk create trunk0 --parent-port port0
  # the type of net1 comes back in the error message (in my environment 'vxlan')
  openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit

  While according to the default policy this information should be admin-only. See around here:
  https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45

  This behavior was introduced in response to this rfe:
  https://bugs.launchpad.net/neutron/+bug/1648129

  Actually sharing this information is the point of the rfe.

  IIRC the concern about the information leak was even raised during a
  review, but it seems it went unaddressed. (Yep, I found the comment
  again: https://review.openstack.org/436756 comment at 03-07 21:12)

  I'm not sure if the segmentation details should be considered
  sensitive information or not. But the current behavior (admin-only
  here, not admin-only there) is clearly inconsistent.

  We could probably solve this by just synchronizing the default
  policies of provider network get operation and subport segmentation
  detail inheritance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1704398/+subscriptions