Re: PostgreSQL Trusted Startup - Mailing list pgsql-general

From Kenneth Buckler
Subject Re: PostgreSQL Trusted Startup
Date
Msg-id AANLkTikCHpgoyG6djtmw99Fp2XDXF_fKc1idEZwYdDv9@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL Trusted Startup  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
On Mon, Dec 20, 2010 at 3:31 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>
>
> But, if the script is run on the same machine as postgresql is on, the
> scripts that check for changes could be compromised as well and then
> you'd never know.
>

I agree, if the system has been compromised, nothing will prevent the
scripts from being compromised.
Hence why I am looking for alternatives.  I consider the md5 script
approach a poor approach, but it does meet the letter of the
requirements set forth by the organization.

> > Is there an alternative method of implementing such a requirement?  Possibly
> > one already incorporated into PostgreSQL?
>
> pgsql doesn't do any of that, but I'm sure you can roll your own so to
> speak.  I would tend to write some kind of nagios plugin that could be
> called remotely that would notify you whenever it changes so you would
> know as soon as a change occurred rather than later when trying to
> restart the database during a midday outage while the boss screams
> "get the system back up now! We're losing money!"
>

Thanks for clarifying that for me.  Part of the requirement I'm
working with requires "vendor documentation" stating if such a feature
exists.  Since there is no vendor documentation, they'll have to
settle for my own documentation, backed up with a mailing list post.

Writing my own plugin/module hasn't been ruled out.  I wanted to make
sure that I'm not re-inventing the wheel.

In any approach to this, I will be including an override which will
allow PostgreSQL to start despite failing the "trusted files" check.

> Generally, if the db's been compromised, someone's already gotten to
> an app server or two, and might be sniffing traffic anyway, so it's
> likely a lost cause by then.

Agreed.  Unfortunately, I've been given specific requirements and I am
obligated to fulfill those requirements, even if I don't agree those
requirements are necessary.  This is all in addition to an extensive
OS lockdown script, as well as additional lockdown requirements for
the database.

I appreciate the help.  I believe this is an excellent starting point
to try and address this requirement.

Ken

pgsql-general by date:

Previous
From: Raimon Fernandez
Date:
Subject: Re: libpq ASYNC with PQgetResult and PQisBusy
Next
From: Alban Hertroys
Date:
Subject: Re: libpq ASYNC with PQgetResult and PQisBusy