RFC: Security documentation

From: "Alex J(dot) Avriette" <alex(at)posixnap(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: RFC: Security documentation
Date: 2004-02-07 18:12:17
Message-ID: 20040207181217.GI7256@posixnap.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)posixnap(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex J. Avriette 2004-02-07 18:29:13 RFC: Very large scale postgres support
Previous Message Bruno Wolff III 2004-02-07 18:09:49 Re: [HACKERS] Aggregation question