Re: SE-PostgreSQL and row level security - Mailing list pgsql-hackers

On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I haven't seen anyone present a shred of evidence that this would be
>> the case in SE-PostgreSQL.
>
> Sorry, but the burden of proof is in the other direction.
>
> In any case, this was already discussed in detail in previous threads.
> It's possible that you could make the database adequately secure given
> appropriate design rules, such as "only use synthetic keys as foreign
> keys".  (For instance consider Kevin's example of needing to hide the
> case caption.  If the caption had been used directly as PK then he'd
> have a problem.)  We have seen no evidence that anyone has a worked-out
> set of design rules that make a SE-Postgres database secure against
> these issues, so the whole thing is pie in the sky.

I agree that it would be useful to have some documentation that
outlines the new covert channels that this creates (by virtue of
blocking the overt channels), approaches to addressing those that can
be addressed, and warnings about those that can't.  I think the only
ones we've been able to come up with so far are:

1. Unique constraints.  If you have insert or update privileges on a
table with unique indices, you might be able to infer the existence of
a hidden row because your insert or update fails despite the fact that
it doesn't conflict with any row that is visible to you.

2. Foreign-key constraints.
(A) If you have update or delete privileges on a table that is
referenced by foreign keys, you might be able to infer the existence
of a hidden, referring row because your update or delete fails.
(B) If you have select privileges on a table which references foreign
keys, you might be able to infer the existence of hidden, referred-to
row on the basis of the fact that there is no visible row to which
your row refers.

Is there anything else?

Problem 1 can be addressed by avoiding creating unique indices on
columns that contain potentially sensitive data.  Probably the most
common examples of unique indices are primary keys, so use non-natural
primary keys.  If you want to avoid inferences about the cardinality
of your data set, don't use serial: instead use UUIDs or similar.

Problems 2(A) and 2(B) can be addressed by setting up the security
labels and policy so that any particular role can see both the
referring row and the referred row, or neither.  Alternatively, the
damage from either can be minimized by using randomized, non-natural
foreign keys as above, so that you learn only that there is a row out
there, but nothing interesting about its contents.

Also, don't problems 2(A) and 2(B) already exist with just table-level
DAC?  What happens today if you give permission on the referring table
but not the referred-to table, or the other way around?

...Robert