Thread: [HACKERS] FIPS mode?

On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
<curtis.ruck+pgsql.hackers@gmail.com> wrote:
> I've got a requirement for enabling FIPS support in our environment.
> Looking at postgresql's be-secure-openssl.c and mucking with it, it seems
> fairly straight forward to just add a few ifdefs and enable fips with a new
> configure flag and a new postgresql.conf configuration setting.
>
> If I clean this up some, maintain styleguide, what is the likely hood of
> getting this included in the redhat packages, since redhat ships a certified
> FIPS implementation?

So they are applying a custom patch to it already?

> For what its worth, I've got the FIPS_mode_set(1) working and postgresql
> seems to function properly.  I'd just like to see this in upstream so I
> don't end up maintaining a long-lived branch.
>
> Looking at scope, logically it seems mostly confined to libpq, and
> be-secure-openssl.c, though i'd expect pgcrypto to be affected.

Yes, I would imagine atht this is located into be-secure-openssl.c and
fe-secure-openssl.c as everything should be done when initializing the
SSL context.

Here is a manual about patch submission:
https://wiki.postgresql.org/wiki/Submitting_a_Patch

As things are now, the next version where new features are accepted
will be 11, with a commit fest beginning in September. Here is its
website where patches need to be registered for review and possible
integration into the tree:
https://commitfest.postgresql.org/
-- 
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
> <curtis.ruck+pgsql.hackers@gmail.com> wrote:
>> If I clean this up some, maintain styleguide, what is the likely hood of
>> getting this included in the redhat packages, since redhat ships a certified
>> FIPS implementation?

> So they are applying a custom patch to it already?

Don't believe so.  It's been a few years since I was at Red Hat, but
my recollection is that their approach was that it was a system-wide
configuration choice changing libc's behavior, and there were only very
minor fixes required to PG's behavior, all of which got propagated
upstream (see, eg, commit 01824385a).  It sounds like Curtis is trying
to enable FIPS mode inside Postgres within a system where it isn't enabled
globally, which according to my recollection has basically nothing to do
with complying with the actual federal security standard.
        regards, tom lane

On 06/23/2017 10:51 PM, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
>> <curtis.ruck+pgsql.hackers@gmail.com> wrote:
>>> If I clean this up some, maintain styleguide, what is the likely hood of
>>> getting this included in the redhat packages, since redhat ships a certified
>>> FIPS implementation?
>
>> So they are applying a custom patch to it already?
>
> Don't believe so.  It's been a few years since I was at Red Hat, but
> my recollection is that their approach was that it was a system-wide
> configuration choice changing libc's behavior, and there were only very
> minor fixes required to PG's behavior, all of which got propagated
> upstream (see, eg, commit 01824385a).  It sounds like Curtis is trying
> to enable FIPS mode inside Postgres within a system where it isn't enabled
> globally, which according to my recollection has basically nothing to do
> with complying with the actual federal security standard.

Yes, see the PostgreSQL DISA STIG for a discussion with respect to that:

https://www.crunchydata.com/postgres-stig/PGSQL-STIG-9.5+.pdf

HTH,

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development