Search Postgresql Archives

Re: PostgreSQL Trusted Startup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 20, 2010 at 3:31 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> 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

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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux