Thread: security

security

From
Ron Peterson
Date:
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 can set table permissions, and even use rules to enforce row level
access rights.  Of course, the PostgreSQL superuser can circumvent any
of these efforts, but that's no different than having root on the OS.

There are a number of reasons I'd like to think this, but just to pick a
concrete example.  Let's say I wanted to implement something analogous
to the unix shadow password file.  I have a table full of usernames and
digested passwords.  I set up a rule so that only the username
associated with a particular record has access to read or modify the
password digest for that record.  Unix file permissions restrict access
to the the data on disk to the postgres user.

This actually seems *more* secure to me than the unix shadow password
file, because I can do row level permission checking.

Is there some reason I'm not thinking of that it would be crazy to
consider using PostgreSQL as a secure data store?  Of course I must
always fear my own incompetance, but that applies to any system, not
just PostgreSQL.

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

Re: security

From
"Karl O. Pinc"
Date:
On 02/05/2005 08:08:00 PM, 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?

Well, from a theoretical perspective you're adding additional levels
of complexity when you use PostgreSQL.  The postgres databases are
in the filesystem, so you don't eliminate complexity there, and
you've added the complexity of a database and a network into the
mix.  With more complexity there's more to go wrong.  I guess the
question is whether the additional complexity buys you additional
security that makes up the difference.

I'd say the answer depends on how badly you need the additional
security.

Otherwise, Idunno.

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



Re: security

From
Steve Atkins
Date:
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?

Theoretically, definitely not if the database is running on the same
machine as the application.

The data is stored as a file on the disk. So all the possible ways I
could read a file I can also read the database. There's no way that
the database can be more secure than "the filesystem" in general[1].

But you're also adding a large number of other ways I can read the
same data, via the database. They're much more complex (and powerful)
than simple filesystem level access. Because of that they're much
harder to audit and more likely to have subtle security flaws than the
filesystem. And it doesn't need to have more flaws than the FS to break
your assertion, just more flaws than zero.

In practice, I suspect you can engineer a pretty nicely secure system
using postgresql as a backing store. Running the database on a secure
host that is externally accessable only from the app that talks to it
would let you avoid (or at least ignore) some issues.

But you need to look at a real threat model and attack tree for your
specific architecture, rather than think about general database
related issues, I think.

Cheers,
  Steve

[1] Yes, postgresql can act as a gatekeeper for access, but so can
    a vastly simpler, much more easily audited dedicated gatekeeper
    application.

Re: security

From
David Fetter
Date:
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.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

Re: security

From
Ron Peterson
Date:
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