| 2021-02-10 18:18:31 |
Andrew Bogott |
bug |
|
|
added bug |
| 2021-02-10 19:37:54 |
Andrew Bogott |
horizon: assignee |
|
Andrew Bogott (andrewbogott) |
|
| 2021-02-10 19:38:18 |
Andrew Bogott |
description |
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related it nonetheless for the odd edge case where it poses a risk. |
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related nonetheless for the odd edge case where it poses a risk. |
|
| 2021-02-10 19:40:15 |
Andrew Bogott |
bug |
|
|
added subscriber Vishal Manchanda |
| 2021-02-10 22:02:36 |
Jeremy Stanley |
description |
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related nonetheless for the odd edge case where it poses a risk. |
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. This
embargo shall not extend past 2021-05-11 and will be made
public by or on that date even if no fix is identified.
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related nonetheless for the odd edge case where it poses a risk. |
|
| 2021-02-10 22:02:51 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2021-02-10 22:03:03 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2021-02-10 22:03:18 |
Jeremy Stanley |
bug |
|
|
added subscriber Horizon Core security contacts |
| 2021-02-12 17:23:15 |
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. This
embargo shall not extend past 2021-05-11 and will be made
public by or on that date even if no fix is identified.
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related nonetheless for the odd edge case where it poses a risk. |
The security group panel enables all actions (create/edit/delete/manage rules/etc.) regardless of the network policy.yaml settings or user account.
In the code there's this telling readme:
# TODO(amotoki): [drop-nova-network] Add neutron policy support
In my deployment this is a bit alarming -- users who are intended to be read-only are nonetheless invited to delete things. Of course the Neutron backend /does/ observe the policy so this is ugly but not usually an actual security risk unless people have different back-end and front-end policy files.
I'm flagging as security-related nonetheless for the odd edge case where it poses a risk. |
|
| 2021-02-12 17:23:25 |
Jeremy Stanley |
information type |
Private Security |
Public |
|
| 2021-02-12 17:23:34 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2021-03-10 05:47:16 |
Vishal Manchanda |
horizon: status |
New |
Fix Released |
|
