Re: Updates of SE-PostgreSQL 8.4devel patches

>> I think you have to resign yourself to the fact that a user who can
>> see only a subset of the rows in a table may very well see apparent
>> foreign-key violations. But so what?
>
> So you're leaking information about the rows that they're not supposed
> to be able to see. This is not what I would call national-security-grade
> information hiding --- leastwise *I* certainly wouldn't store nuclear
> weapon design information in such a database. The people that the NSA
> wants to defend against are more than smart enough, and persistent
> enough, to extract information through such loopholes.

If your plan is to refuse to implement row-level security until
someone produces a design that can never leak information under any
circumstances regardless of how the user configures it, then I
strongly suspect we'll be waiting forever. The designs being put
forward here are capable of being configured in an insecure fashion,
but that's true of any other security mechanism we offer, too.

SE-PostgreSQL needs to be good enough for the NSA, but row-level
security in general does not. Right now, for example, there's no way
to say "I'd like user X to be able to insert rows into this table, and
update and delete the rows they insert, but not update or delete any
rows that don't belong to them" or "I'd like to give user X the
ability to see certain rows in this table, but not all of them." If
the table in question has foreign keys, the database administrator can
make the referenced tables fully visible, or can make sure that the
slices of each table that are visible correspond to one another... or
he can do some crazy, illogical thing that makes no sense and creates
all sorts of apparent referential integrity violations.

But I don't see how any design is going to avoid an administrator
doing crazy, illogical things that make no sense. I'm sure it's
possible to label your SELinux filesystem in a crazy, illogical way,
too.

An orthogonal approach to this problem would be to allow permission
grants that act like a constraint check, rather than applying security
attributes to individual tuples. So for example you could allow
SELECT access to the slice of a table where <some column> = <some
value>. You'd probably want to allow (a) SELECT constraint (must hold
for a tuple to be visible), (b) INSERT constraint (must hold for each
tuple being inserted), (c) BEFORE UPDATE constraint (must hold of each
tuple about to be updated), (d) AFTER UPDATE constraint (must hold of
each new tuple produced by an update), and (e) DELETE constraint (must
hold of each tuple to be deleted). SELECT, BEFORE UPDATE, and DELETE
would silently pass over failing tuples, while INSERT and AFTER UPDATE
would throw an error. I'm sure this wouldn't satisfy the SELinux
folks, but I suspect it has a lot of more mundane applications, and it
avoids the need to store a security attribute on every tuple.

...Robert