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

Sun, 8 Feb 2004 23:24:56 -0800
Josh Berkus <josh@agliodbs.com>
Re: RFC: Security documentation
Alex,

> I find myself wondering what other people are doing with postgres that
> this doesn't seem to have come up. When one searches for postgres
> clustering on google, they will find lots of HA products. However,
> nobody seems to be attempting to create very high throughput clusters.

Have you checked out "Clusgres" from Linux Labs?   One of my clients will be 
testing this application soon.

While we haven't run into transaction throughput limits, a couple of my 
client's seem to be running in x86's limits on very large queries, 
particularly on vendor hardware.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Sun, 8 Feb 2004 23:27:29 -0800
Josh Berkus <josh@agliodbs.com>
Re: RFC: Very large scale postgres support
On Sun, Feb 08, 2004 at 11:24:56PM -0800, Josh Berkus wrote:
> 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.
 
Perhaps what would be best is some kind of a 'best practices' guide.
There's far more that people should consider beyond just quoting
strings; Josh's example is just one thing.

If written carefully, such a guide could serve both experienced DBAs as
well as people who are very new to databases, since every database has
it's own prefered way of doing things.
-- 
Jim C. Nasby, Database Consultant                  jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Wed, 11 Feb 2004 11:46:24 -0600
"Jim C. Nasby" <jim@nasby.net>
Re: RFC: Security documentation
On Wednesday 11 February 2004 12:46, Jim C. Nasby wrote:
> On Sun, Feb 08, 2004 at 11:24:56PM -0800, Josh Berkus wrote:
> > 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.
>
> Perhaps what would be best is some kind of a 'best practices' guide.
> There's far more that people should consider beyond just quoting
> strings; Josh's example is just one thing.
>
> If written carefully, such a guide could serve both experienced DBAs as
> well as people who are very new to databases, since every database has
> it's own prefered way of doing things.

Was thinking if somene want to write up a series of articles discussing 
security best practices, this might be a good starting point since it would 
require somone to have everything figured out before getting started; you 
could pick a certain section and get specific about it. We have the 
infrastructure on techdocs to publish this, and once started we could use it 
to determine what should or should not be added to the standard docs. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Sun, 15 Feb 2004 12:13:58 -0500
Robert Treat <xzilla@users.sourceforge.net>
Re: RFC: Security documentation