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 <t...@sss.pgh.pa.us> wrote:

> Michael Paquier <michael.paqu...@gmail.com> writes:
> > On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck
> > <curtis.ruck+pgsql.hack...@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
>

[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.

Re: [HACKERS] PostgreSQL Auditing

[curtis . ruck]

Its not available in rpm or premade binary forms in its current instantiation, 
not a big deal for me, but it raises the barrier to entry.

If it was packaged into an RPM, what would be the process to get it added to 
postgresql's yum repositories?

February 2 2016 10:24 AM, "Joshua D. Drake" <j...@commandprompt.com> wrote:
> On 02/02/2016 02:47 AM, José Luis Tallón wrote:
> 
>> On 02/02/2016 02:05 AM, Curtis Ruck wrote:
>>> [snip]
>>> 
>>> P.S., do you know what sucks, having a highly performant PostGIS
>>> database that works great, and being told to move to Oracle or SQL
>>> Server (because they have auditing). Even though they charge extra
>>> for Geospatial support (seriously?) or when they don't even have
>>> geospatial support (10 years ago). My customer would prefer to
>>> re-engineer software designed around PostgreSQL and pay the overpriced
>>> licenses, than not have auditing. I agree that their cost analysis is
>>> probably way off, even 10 years later, my only solution would be to
>>> move to Oracle, SQL Server, a NoSQL solution, or pay EnterpriseDB for
>>> their 2 year old version that doesn't have all the cool/modern jsonb
>>> support.
> 
> PostgreSQL has auditing. It is available now, just not in core. Postgis isn't 
> available in core
> either and it seems to do just fine.
> 
> JD
> 
> -- Command Prompt, Inc. http://the.postgres.company
> +1-503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Everyone appreciates your honesty, until you are honest with them.


-- 
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] PostgreSQL Auditing

[Curtis Ruck]

Robert,

This isn't wrong.  I don't see anyone else trying to submit anything in
reference to auditing.  Just because there have been multiple
implementations in the past, based on commit histories, there have only
been a few that tried getting into core or contrib (that i can find in
mailing list history).  Currently, in 9.6, there is one version that is
trying to make it in.  If Crunchy, or 2nd Quadrant, tried to get their
versions incorporated we would have a disagreement in implementation, but
either they are lying in wait, or they passively concur, by not actively
disagreeing.

I think if there was a valid commit path laid out for getting auditing into
core, or into contrib at least, most users would probably find that
sufficient.  But it seems that every time someone tries to incorporate
auditing, there are countless and varied reasons to deny its inclusion.

David Steele's version of auditing builds on most of the prior pgaudit code
and incorporates a large amount of the feedback from 9.5's attempt.

I'm opening to testing and evaluating to see if it meets our compliance
requirements, but I am no where close to being a C developer, or having C
developers that could actually provide a meaningful review.  One issue
along this thread already pops up, concerning the client_min_messages, and
how other patches in the pipeline for 9.6 would be required to enable the
auditing to meet compliance requirements.

It just seems after reading the mailing list history, that there is a lack
of interest by people with commit authority, even though there is a decent
interest in it from the community, and honestly, no one really likes
auditing, but its one of those damned if you do (in performance) and damned
if you don't (in legal) things.

Additionally Robert, given your professional status, you are by no means an
unbiased contributor in this discussion.  Your stance on this matter shows
that you don't necessarily want the open source solution to succeed in the
commercial/compliance required space.  Instead of arguing blankly against
inclusion can you at least provide actionable based feedback that if met
would allow patches of this magnitude in?

I'm personally fine with fiscally rewarding organizations that assist my
customer in succeeding, but its hard to convince my customer to fund open
source, even though they wouldn't be able to do 75% of what they do without
it.  Based on past experience this is the same most open source
organizations face, especially when they don't have the marketing engine
that the large commercial players have.

Curtis

…

On Tue, Feb 2, 2016 at 5:23 PM Robert Haas  wrote:

> On Tue, Feb 2, 2016 at 5:16 PM, David Steele  wrote:
> > This sort of confusion is one of the main reasons I pursued inclusion in
> > core.
>
> But that's exactly wrong.  When there is not agreement on one code
> base over another, that's the time it is most important not to pick
> one of them arbitrarily privilege it over the others.  The *only* time
> it's appropriate to move something that could just as well as an
> extension into core is when (1) we think it's highly likely that users
> will want that particular thing rather than some other thing and (2)
> we think it's worth the burden of maintaining that code forever.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

[HACKERS] PostgreSQL Auditing

[Curtis Ruck]

So Auditing, it seems that some people want auditing (myself, David Steele,
2nd quadrant, and probably others).  I personally love postgresql, but
until it can meet my annoying compliance requirements, I can't leverage it
fully as my organization spends more time on meeting compliance, than
actually doing development and engineering.

Sadly, due to the incumbent solutions in the database arena, we are also
wasting idiotic amounts of time, money, and increasing system complexity
because we are having to use alternative solutions that provide things like
auditing.

If David's auditing patch isn't sufficient, what is?  Are we waiting on the
holy grail of auditing, which implements an entirely new logging subsystem,
and hooks so deeply into the innards of PostgreSQL its perfect?  Does this
mailing list just not care about the potential customers (and potential
financial benefits) of providing a complete database solution?  Or does the
postgresql community just want to stay a hobbyist database that never
broaches the enterprise or compliance arenas?

I've worked with many database vendors, and honestly auditing is fairly
bland, its boring, and no one really likes it except for the lawyers, and
then only when someone was actually caught doing something wrong, which
lets face it is quite infrequent given the number of databases that exist
out there.

Just because auditing isn't sexy sharding, parallel partitioning, creative
indexing (BRIN), or hundreds of thousands of transactions a second, doesn't
make it any less of a requirement to countless organizations that would
like to use postgresql, but find the audit requirement a must have.

So, in summary, what would it take to get the core PostgreSQL team to
actually let auditing patches into the next version?

P.S., do you know what sucks, having a highly performant PostGIS database
that works great, and being told to move to Oracle or SQL Server (because
they have auditing).  Even though they charge extra for Geospatial support
(seriously?) or when they don't even have geospatial support (10 years
ago).  My customer would prefer to re-engineer software designed around
PostgreSQL and pay the overpriced licenses, than not have auditing.  I
agree that their cost analysis is probably way off, even 10 years later, my
only solution would be to move to Oracle, SQL Server, a NoSQL solution, or
pay EnterpriseDB for their 2 year old version that doesn't have all the
cool/modern jsonb support.