Thread: Postgres Security Checklist

Hi, I'm developing a Graduation Work about Database security. My idea is develop an application that connect in an database (in this case Postgres) and make some security verification of that db. The problem is that my verification only can be in a dabatase scope. I can't include Network and OS threats.
Unfortunaly i didn't find a good material about postgres security. The good things that i found (articles and checklists) were about MSQLSERVER and Oracle.
I would like to know if you have any material about this subject (book, article, checklists and etc) that eventualy could help me in this work.

Tranks!


Eduardo Henrique(Hitek) - www.eduardohitek.blogspot.com
Desenvolvimento
SoftSite - www.softsite.com.br

Eduardo Henrique wrote:
> Hi, I'm developing a Graduation Work about Database security.
> My idea is develop an application that connect in an database
> (in this case Postgres) and make some security verification
> of that db. The problem is that my verification only can be
> in a dabatase scope. I can't include Network and OS threats.
> Unfortunaly i didn't find a good material about postgres
> security. The good things that i found (articles and
> checklists) were about MSQLSERVER and Oracle.
> I would like to know if you have any material about this
> subject (book, article, checklists and etc) that eventualy
> could help me in this work.

Here is my personal security checklist for PostgreSQL:

- Check that there is no SQL function with SECURITY DEFINER.
- Check that only the DBA has SUPERUSER, CREATEDB oder CREATEROLE privileges.
- Check that no password is equal to the user name or some "initial standard password" that your company uses.
- Check that ssl=on.
- Check that nobody except for superusers has any privileges on pg_catalog.pg_authid.
- Check that you are running the latest release for your version of PostgreSQL.
- Check that no privileges on objects are granted to PUBLIC.
- Check that no privileges on objects were granted WITH GRANT OPTION.
- Check that only local users have "trust" authentication in pg_hba.conf.
- Check that pg_hba.conf forces remote connections to use SSL.
- Check that pg_hba.conf forbids remote connections to use "password", "crypt" or "ident" authentication.

Most of these can be checked with normal SQL statements. For the ones
that have to examine pg_hba.conf, I use an untrusted PL/Perl function
that reads the file.

Yours,
Laurenz Albe

"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Here is my personal security checklist for PostgreSQL:

> - Check that there is no SQL function with SECURITY DEFINER.

Uh, that seems a pretty strange restriction.  Generally, if you are
actually concerned about security at the SQL-command level, you're
going to have to have some SECURITY DEFINER functions.  You can't
build a Unix system without suid programs, either.

> - Check that pg_hba.conf forbids remote connections to use "password", "crypt" or "ident" authentication.

Most people think that remote "ident" is not very secure.

            regards, tom lane

Tom Lane wrote:
> > Here is my personal security checklist for PostgreSQL:
>
> > - Check that there is no SQL function with SECURITY DEFINER.
>
> Uh, that seems a pretty strange restriction.  Generally, if you are
> actually concerned about security at the SQL-command level, you're
> going to have to have some SECURITY DEFINER functions.  You can't
> build a Unix system without suid programs, either.

I was referring to
http://archives.postgresql.org/pgsql-general/2007-02/msg00646.php

I should have been more precise - I mean "functions with LANGUAGE SQL".

I guess the security leak is fixed with the SET clause in CREATE FUNCTION,
so this is probably obsolete.

> > - Check that pg_hba.conf forbids remote connections to use "password", "crypt" or "ident" authentication.
>
> Most people think that remote "ident" is not very secure.

That's what I mean.
Again, I should have been more precise:
- Make sure that pg_hba.conf does not permit remote connections to use
  "password", "crypt" or "ident" authentication.

Yours,
Laurenz Albe