[Openstack-operators] Raising the degree of the scandal
Miguel Ángel Ajo
majopela at redhat.com
Sun May 17 13:33:48 UTC 2015
Probably the solution is not selected to be backported because:
* It’s an intrusive change
* Introduces new dependencies
* Probably it’s going to introduce a performance penalty because eatables is slow.
I’m asking in reviews for this feature to be enabled/disabled via a flag.
In the future I hope OVS with connection tracking to be merged, so then we can
finally have a proper openvswitch_firewall_driver supporting stateful firewalling
without reflective rules or flag matching (one is slow, the other is insecure…)
Miguel Ángel Ajo
On Saturday, 16 de May de 2015 at 23:28, George Shuklin wrote:
> On 05/15/2015 07:48 PM, Jay Pipes wrote:
> > On 05/15/2015 12:38 PM, George Shuklin wrote:
> > > Just to let everyone know: broken antispoofing is not an 'security
> > > issue' and the fix is not planned to be backported to Juno/kilo.
> > >
> > > https://bugs.launchpad.net/bugs/1274034
> > >
> > > What can I say? All hail devstack! Who care about production?
> > George, I can understand you are frustrated with this issue and feel
> > strongly about it. However, I don't think notes like this are all that
> > productive.
> > Would a more productive action be to tell the operator community a bit
> > about the vulnerability and suggest appropriate remedies to take?
> Ok, sorry.
> Short issue: If few tenants use same network (shared network) one tenant
> may disrupt network activities of other tenant by sending a specially
> crafted ARP packets on behave of the victim. Normally, Openstack
> prohibit usage of unauthorized addresses (this feature is called
> 'antispoofing' and it is essential for multi-tenant clouds). This
> feature were subtly broken (malicious tenant may not use other addresses
> but still may disrupt activities of other tenants).
> Finally, that bug has been fixed. But now they says 'oh, it is not that
> important, we will not backport it to current releases, only to
> "Libery"' because of new etables dependency.
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org (mailto:OpenStack-operators at lists.openstack.org)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators