Comments on: securing your postgresql database

By: Dicas-L Infraestrutura para Aplicações Web Seguras parte 2 – SGBDs « .Info – windows, linux, software e mais.

Tue, 09 Mar 2010 11:11:49 +0000

[...] Securing your PostgreSQL Database [...]

By: Infraestrutura para Aplicações Web Seguras parte 2 – SGBDs | Alexos Core Labs

Fri, 26 Feb 2010 02:01:58 +0000

[...] Securing your PostgreSQL Database * PostgreSQL – [...]

By: Segurança em bancos de dados PostgreSQL | Israel Junior

Segurança em bancos de dados PostgreSQL | Israel Junior — Mon, 03 Mar 2008 11:40:15 +0000

[...] passada encontrei um post bem interessante sobre segurança em bancos de dados PostgreSQL. O artigo é velhinho e vai fazer aniversário em 18 de agosto, mas as dicas são de extrema [...]

By: depesz

depesz — Fri, 21 Sep 2007 21:09:27 +0000

apparently revoking access to pg_catalog doesn’t fully work. tom lane responded to my mail fo pgsql-bugs (http://archives.postgresql.org/pgsql-bugs/2007-09/msg00059.php), but as i understand it is not supported, and will not work fully.

this of course allows user to see sources of your functions, but i dont see it as a big threat. if your database is protected using proper revokes, knowing source codes of functions will not help much – after all – data will still be secure.

By: semartin

semartin — Mon, 10 Sep 2007 12:53:29 +0000

Reading this thread (answer from Tom Lane)
http://www.issociate.de/board/post/429754/Revoking_usage_of_pg_catalog.html
makes you wonder if access to certain objects is necessary for database to respond to user requests.
Or am I missing something since I’m using PostgreSQL on a “need-to-know” basis?
Oh, I almost forgot: thanks for your effort on this site.

By: depesz

depesz — Mon, 10 Sep 2007 12:32:27 +0000

@semartin:
i mailed buginfo about it. will see how it will go

By: depesz

depesz — Mon, 10 Sep 2007 12:22:16 +0000

@semartin:
apparently it is possible. it looks like a bug though.

depesz

By: semartin

semartin — Mon, 10 Sep 2007 12:15:45 +0000

After revoking usage privileges on schema pg_catalog from public user webapp still runs queries such as “select * from pg_tables” or “select * from pg_user” and inspects database internals.
Are those queries permitted regardless of user rights on schema and corresponding objects?

By: Log Buffer #59: a Carnival of the Vanities for DBAs « I’m just a simple DBA on a complex production system

Fri, 24 Aug 2007 16:05:55 +0000

[...] Meanwhile, on the OpenSource web: Ronald, at Technical Notes blog posts a bunch of links for Oracle DBAs learning MySQL and also advice regarding backup and recovery. Last week I received a task to take ownership of MySQL server and write a recovery procedure for it, I can testify that both articles are very useful. Charlie Cahoon ends in his Summer of Code blog with a release of his MySQL proxy. Corra is already using MySQL Proxy on Ubuntu. Morgan Tocker and Brian “Krow” Aker try to decide how big transactions should be, and last but not least explains how to secure PostgreSQL. [...]

By: PDK

PDK — Thu, 23 Aug 2007 19:43:40 +0000

You’re welcome, I try to help where I can.

By: depesz

depesz — Wed, 22 Aug 2007 18:59:29 +0000

@PDK:
i didn’t mention it for a very simple reason – i didn’t know anything about kerberos authentication as i never used it

so, thanks for valuable input – without your comment there was no chance i will write anything about it, but now the tutorial (with comments) give more information then i have

By: PDK

PDK — Wed, 22 Aug 2007 18:50:54 +0000

Good tutorial, however I feel I should point out that disallowing remote superuser connections won’t work in the case of Kerberos authentication. Granted, this is probably the exception among postgresql users, but I’m sure enough people use it.

However, you can essentially block remote superuser connections by limiting credentials and login shells only to postgres servers, and making sure that only people and admins you trust can log in and use said superuser.

Still, it should be noted that Kerberos uses TCP/IP and currently cannot use Unix Domain Sockets, if that makes any difference.

By: EdwinF

EdwinF — Wed, 22 Aug 2007 15:41:43 +0000

Simply great, thnx a bunch!.

By: depesz

depesz — Mon, 20 Aug 2007 06:35:55 +0000

@Mathew:
i didn’t because i think that:
1. every admin should know it
2. i write specifically about postrgesql, and chrooting (and other things like this) are mostly general, not application dependant

maybe in future, if i’ll have too much free time

By: Mathew

Mathew — Mon, 20 Aug 2007 00:27:53 +0000

Good read – picked up some things I hadn’t thought about before.

Given that you kept he discussion “inside” PostgreSQL you didn’t mention classics that every admin should know – like chrooting. Might make a good part 2?

By: depesz

depesz — Sun, 19 Aug 2007 18:09:29 +0000

i connect over unix socket *only* on devel machines. (on servers postgresql is in chroot, and applications are in chroots, so connecting over unix socket would be … complicated).

on devel machine i want to be able to simply \c – postgres. i want to be able to psql -U postgres -d template1.
and “ident” breaks it for me.

i know i can “fix” it by using pg_ident.conf, but if i have to fix it that way – i much more prefer “trust”.

additionally – i hate it because it is one of the most common problems with fresh postgresql instalation. (this, tcpip socket, and “user root does not exist ”.

By: Screwtape

Screwtape — Sun, 19 Aug 2007 08:54:46 +0000

I’m curious – why do you hate “ident sameuser” so much? Granted, it’s horribly broken over TCP-IP, but if you’re on an OS that supports SO_PEERCRED and you’re connecting over a Unix-domain socket, this form of identification is apparently unspoofable – surely that’s a good thing?

By: xor

xor — Sun, 19 Aug 2007 08:20:05 +0000

Thank you!