Open Stack

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