Re: RFC: Security documentation - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: RFC: Security documentation
Date
Msg-id 200402082324.56996.josh@agliodbs.com
Whole thread Raw
In response to RFC: Security documentation  ("Alex J. Avriette" <alex@posixnap.net>)
Responses Re: RFC: Security documentation  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
Alex,

> As such, I would like to see some documentation about securing the
> database at a data and application level. It would be nice to have some
> general guidelines, as well as being able to cite documentation when
> setting up a security policy for a database application.

I'd be happy to participate in discussing security strategies for PostgreSQL 
databases; I do a bit of this for my clients though, not, I think, on the 
level of need you face.   A lot can be done especially with 7.4 by 
manipulating permissions, obfuscating database objects through views, 
functions, and rules, and otherwise "locking down" database objects.  For 
example, if the web server user's only access to a table is via a 
set-returing search function, and that user has no other permissions, a SQL 
injection attack isn't going to obtain anything other than an error.

The problem with this approach, of course, is that large application 
developers generally like to make the database fairly "passive" and put all 
business & security logic in the middleware.   I do think it would be useful 
for them to realize that they are sacrificing a significant portion of their 
data security by doing so.

On a machine/network level, all I really do is lock down port access to the 
database server, and make sure that the db server has no ports that point to 
unsecured networks (as well as the usual user/database/password 
restrictions).    My general perspective is that if an attacker can gain 
unrestricted port access to the database, a break-in is only a matter of time 
-- if through nothing else than password-guessing attacks.

I'm not sure such a paper is appropriate for the main docs.  But it is 
definitely appropriate for TechDocs.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Timestamps
Next
From: Josh Berkus
Date:
Subject: Re: RFC: Very large scale postgres support