Re: Hiding data in postgresql

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Hiding data in postgresql
Date: 2010-05-25 10:47:31
Message-ID: 20100525104731.GG20550@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, May 24, 2010 at 05:04:10PM -0400, Merlin Moncure wrote:
> Let me humbly state that the #1 problem that beginners face with
> security and encryption is focusing too much on the mechanics and not
> enough on the 'big picture' issues:

One more that OP seems to be avoiding is why would anybody want to do
this anyway? There are plenty of places that will happily host data for
you--most email sites give you many gigabytes of storage these days.
Seems to be a solution in search of a problem to me.

I think what the OP may be asking is about the presence of "covert
channels". There are plenty of these in PG, an attacker can do the
obvious things like disguising data inside other data (steganography) or
more subtle things like tuple order on disk, transaction orderings, or
interactions between running queries (i.e. causing one to pause for a
few milliseconds by reading/locking a table).

Covert channels seem to be a fundamental fact of nature. As far as I
know, though I'm not aware of any papers directly on the subject, it's
*always* possible to design a new attack by exploiting the physical
implementation of something. Hence any specific tool you design to look
for any specific attack can always be avoided in an infinite number of
ways, generally negating its purpose. You have to be much more specific
in your requirements before useful analysis can be done.

What can be done is to reduce the bandwidth of a specific covert
channel, and beyond some threshold it *may* be possible to say that "no
useful data can be transmitted", but that's about it. If somebody just
wants to leak a password/private key a surprisingly few number of bits
will go a long way.

--
Sam http://samason.me.uk/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message A. Kretschmer 2010-05-25 11:13:40 Re: pg_dump cannot connect when executing by a script
Previous Message Leif Biberg Kristensen 2010-05-25 10:45:09 Re: uppdate from postgersql 8.3.7 to 8.4.4

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-25 10:57:12 Re: JSON manipulation functions
Previous Message Florian Pflug 2010-05-25 10:46:25 Re: ROLLBACK TO SAVEPOINT