Re: PostgreSQL Trusted Startup

On Mon, Dec 20, 2010 at 3:31 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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