Re: [HACKERS] FIPS mode?

[Curtis Ruck]

To utilize openssl FIPS, you have to explicitly enable it, per the FIPS
user guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

So, my target would be redhat/centos where openssl FIPS is
certified/available, and then add a configuration parameter to enable it
(much like Apache HTTPD's SSLFIPS directive:
http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslfips).

On Sat, Jun 24, 2017 at 1:51 AM Tom Lane  wrote:

> Michael Paquier  writes:
> > On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
> >  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
>

Re: [HACKERS] FIPS mode?

[Joe Conway]

On 06/23/2017 10:51 PM, Tom Lane wrote:
> Michael Paquier  writes:
>> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
>>  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



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] FIPS mode?

[Tom Lane]

Michael Paquier  writes:
> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
>  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] FIPS mode?

[Michael Paquier]

On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] FIPS mode?

[Curtis Ruck]

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?

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.