Open Stack

I completely agree that this shall be upstream first. So the main effort
will be on landing this python patch first. This has been up since 2010, so
more effort in terms of code contribution and reviews is needed, I'm happy
to collaborate in amending the patch as the reviews are requesting.

But the general idea is still there, and that's why a wrapper can make
sense. Even if the final patch has a different signature, or a different
functionality, the idea is the same: don't block md5 if that's not used for
security.

Even if the python patch lands, this would be in 3.7 and this version
adoption can take long in OpenStack. And enabling FIPS kernel is an
important security feature that we shall cover, if we just wait for the
patch to land it can take long time. The wrapper can be the short-term
solution as Doug says, allowing us to enable this important feature.

On Tue, Jan 17, 2017 at 5:51 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

> Excerpts from Ian Cordasco's message of 2017-01-17 05:59:13 -0600:
> > On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota <yroblamo at redhat.com>
> wrote:
> > > Hi, in previous threads, there have been discussions about enabling
> FIPS,
> > > and the problems we are hitting with md5 inside OpenStack:
> > > http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107035.html
> > >
> > > It is important from a security perspective to enable FIPS, however
> > > OpenStack cannot boot with that, because of the existence of md5 calls
> in
> > > several projects. These calls are not used for security, just for hash
> > > generation, but even with that, FIPS is blocking them.
> > >
> > > There is a patch proposed for newest versions of python, to avoid that
> > > problem. The idea is that when a hash method is called, users could
> specify
> > > if these are used for security or not. If the useforsecurity flag is
> set to
> > > False, FIPS won't block the call. See: http://bugs.python.org/
> issue9216
> >
> > This patch looks to have died off in 2013 prior to Robert's comment from
> today.
> >
> > > This won't land until next versions of Python, however the patch is
> already
> > > on place for current RHEL and CentOS versions that are used in
> OpenStack
> > > deploys. Using that patch as a base, I have a proposal to allow FIPS
> > > enabling, at least in the distros that support it.
> > >
> > > The idea is to create a wrapper around md5, something like:
> > > md5_wrapper('string_to_hash', useforsecurity=False)
> >
> > We should probably work harder on actually landing the patch in Python
> > first. I agree with Robert that the optional boolean parameter is
> > awkward. It'd be better to have a fips submodule.
>
> Please see my comment on that patch about why that approach doesn't
> solve the problem.
>
> > > This method will check the signature of hashlib.md5, and see if that's
> > > offering the useforsecurity parameter. If that's offered, it will pass
> the
> > > given parameter from the wrapper. If not, we will just call
> > > md5('string_to_hash') .
> > >
> > > This gives us the possibility to whitelist all the md5 calls, and
> enabling
> > > FIPS kernel booting without problems. It will start to work for distros
> > > supporting it, and it will be ready to use generally when the patch
> lands in
> > > python upstream and another distros adopt it. At some point, when all
> > > projects are using newest python versions, this wrapper could
> disappear and
> > > use md5 useforsecurity parameter natively.
> >
> > I'd much rather have the upstream interface fixed in Python and then
> > to have a wrapper that does things the correct way. Otherwise, we're
> > encouraging other distros to use a patch that still requires a lot of
> > edits to address the review comments and might be defining an API that
> > will never end up in Python.
> >
> > > The steps needed to achieve it are:
> > > - create a wrapper, place it on some existing project or create a new
> fips
> > > one
> > > - search and replace all md5 calls used in OpenStack core projects ,
> to use
> > > that new wrapper. Note that all the md5 calls will be whitelisted by
> > > default. We have not noted any md5 call that is used for security, but
> if
> > > that exists, it shall be better to use another algorithms, in terms of
> > > security.
> > >
> > > What do people think about it?
> >
> > I think people should work on the Python patches *first*. Once they're
> > merged, *then* we should potentially create a wrapper (if it's still
> > necessary at that point) to do this.
> >
>
> The idea is to use the wrapper as a short-term solution to give us the
> time to make that happen. The original patch did lose interest, but even
> if it landed today it wouldn't necessarily be the sort of thing that
> would qualify for a backport, so it might take quite a while to see a
> real release.
>
> As you point out, the final version of the upstream API may be
> different. With a wrapper in place, we ought to be able to modify the
> implementation of the wrapper to accommodate that to ensure backwards
> compatibility, during the deprecation period after the upstream fix is
> implemented.
>
> Doug
>
> __________________________________________________________________________
> 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
>



-- 
Yolanda Robla Mota
NFV Partner Engineer
yroblamo at redhat.com
+34 605641639
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170117/00eca739/attachment.html>