Open Stack

No, there haven't been vulnerabilities where the rules you expressed in the
API were not rendered as requested (unless there was a denial of service in
which case the whole dataplane would fail to wire). The issues were people
being able to escape their own anti-spoofing filtering so they could do IP
spoofing and ARP poisoning. VM-local firewalls would not have helped in
this case.
On Mar 2, 2016 10:50 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:

> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote:
> > Kevin Benton wrote:
> > > * Neutron cannot be trusted to do what it says it's doing with the
> security
> > > groups API so users want to orchestrate firewalls directly on their
> > > instances.
> >
> > This one really rubs me the wrong way. Can we please get a better
> > description of the bug - instead of someone just saying that Neutron
> > doesn't work, therefore we don't want any filtering or security for our
> > instances using an API?
>
> Sure. There are two ways this manifests. The first is that there have
> been bugs in security groups where traffic is passed despite being told
> not to pass that traffic. This has been treated as a bug in the past and
> corrected which is great so this particular instance of the issue is
> less worrysome. The second is that I will explicitly tell neutron to
> pass traffic but for whatever reason that traffic ends up being blocked
> anyways. One concrete example of this is the infra team has had to stop
> using GRE because at least two of our clouds do not pass GRE traffic
> despite having explicit "pass all ipv4 and all ipv6 between all possible
> addresses rules".
>
> Security groups need to do what I have told them to do and when they
> don't it is almost impossible as a cloud user to debug them.
>
> Clark
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160302/436d7a80/attachment.html>