RFC: Security documentation - Mailing list pgsql-hackers

From Alex J. Avriette
Subject RFC: Security documentation
Date
Msg-id 20040207181217.GI7256@posixnap.net
Whole thread Raw
Responses Re: RFC: Security documentation  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
Re: RFC: Security documentation  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Hello again.

Recently, an application of mine, which faces the internet, came under
attack. The form of the attack was the standard DOS attack. Open a
bunch of sockets, don't close them, and see if you can break the
availability of the application.

This attack came within six hours of the application going live. While
I can't give details, I can say that this application is running within
a very high visibility organization, and we are more or less under
continual attack of various forms.

I realized that a DOS attack was relatively unsophisticated, and that
over the lifetime of this product, we will se more concerted,
intelligent attacks on our code. This is troubling to me. When I began
searching for documentation on securing postgres, all of the available
docs seem to focus on access to the database through pg_hba.conf.

While I can appreciate that this is useful (eg using ssl and md5
instead of plaintext trusted accounts), I feel that there is
substantial documentation missing on securing it at an application
level.

I mentioned some time ago, that on IRIX, it is possible to crash the
postmaster by feeding it 'select 1/0'. My concern was that something
like this might come down the pipe, or somebody may be passing in the
de rigeur '; select * from sensitive_table; ...' attempts (this is very
common, as you know, in CGI applications).

The program in question is a set of stored procedures which are called
from Perl libraries (via DBD::Pg) I can't think of any way to ensure
that malicious input is sanitized, from within plpgsql. From within
perl, I can use DBI::quote, or I can come up with my own function using
y///.

But when I began asking people what the "final word" was on the
subject, if there was somebody who was willing to suggest a path to
data security and stick by it, nobody could point you anywhere.
Essentially, it boils down to this:  I can't put in the documentation
for my application "well, some guy on IRC said that this was safe
enough." I'd be fired if the application was compromised and the only
checking I had done was by asking people on IRC.

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.

That having been said, I would have submitted a patch with said
documentation if I knew where to start. I have submitted this RFC -- a
request for comments, nothing more serious than that -- because I'd
like to know what we can do to get some documentation included in the
next release. I don't feel that having zero documentation on this 
subject is acceptable.

Thanks for your time,
alex

--
alex@posixnap.net
Alex J. Avriette, Unix Systems Gladiator
"You cannot invade the mainland United States. There would be a rifle behind each blade of grass." - Admiral Isoroku
Yamamoto
 


pgsql-hackers by date:

Previous
From: Hans-Jürgen Schönig
Date:
Subject: Re: Aggregation question
Next
From: Bruno Wolff III
Date:
Subject: Re: Aggregation question