Re: security

On Sat, Feb 05, 2005 at 11:00:28PM -0800, David Fetter wrote:
> On Sat, Feb 05, 2005 at 09:08:00PM -0500, Ron Peterson wrote:
> > I would like to be able to assert that the security of data stored
> > as a value in a PostgreSQL table can be as high as the security of
> > saving that same piece of data to a file on disk.  Would that be
> > correct?
>
> I hate to put it so bluntly, but "security" isn't a product that you
> buy or a service that you use.  It's not even a rigid set of
> procedures, however well-thought-out such a set might be.
>
> Instead, it's a large and by its nature flexible set of processes that
> you must implement and keep up to date.  What distinguishes security
> in the computer field from other kinds of things involving computers
> is the existence of one or more attackers.  In re: how to do security,
> I'll quote Bruce Schneier's 5-step security evaluation:
>
>    1. What assets are you trying to protect?
>    2. What are the risks to those assets?
>    3. How well does the security solution mitigate those risks?
>    4. What other risks does the security solution cause?
>    5. What costs and tradeoffs does the security solution impose?
>
> Until you have answered questions 1 and 2, you can't even start on an
> implementation.

Sure, I agree with all of that.  Those are useful abstractions which
basically say that at some point, you need to stop thinking in
abstractions, and get down to brass tacks.

Using the term "secure" in a loose sense, clearly I hope we can consider
it's possible to create secure database applications in PostgreSQL.
Otherwise we can tell our clients that PostgreSQL is an inappropriate
place to consider storing sensitive information.

It's the brass tacks stuff I'd like feel I have a really firm grip on.
I've searched, but have not yet found anything resembling a "security
best practices" howto for PostgreSQL.  I think I have a reasonable grasp
of what needs to be done to secure a database application, but I'm
worried about that one thing I'm overlooking that leaves me wide open
(memory scrubbing?, etc.).  As others have said, the additional
complications PostgreSQL introduces are the most probable cause of
weakness.  On the other hand, I don't feel that PostgreSQL is *so*
complicated, that those complications can't be dealt with.  For example,
I agree with Steve Atkins' point that running the database on a separate
host eliminates or at least reduces the potential impact of a whole host
of issues.

Does anyone know of a best practices security checklist for PostgreSQL?
Or any other resources in that vein?

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College
http://www.mtholyoke.edu/~rpeterso