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
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 |