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
Re: RFC: Security documentation |
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: