> I think there is another "covert channel" much more serious than > constrains. You can gather information about hidden data by reading > query plans.
I think a lot of people would be quite happy to simply disallow EXPLAIN. Define a permission for it, grant it to public and newly created users/groups by default (for BC), and allow it to be revoked. To define what is/isn't reasonable in terms of covert channel leakage, I (reluctantly) suggest checking out the Common Criteria stuff. Yes, it's verbose and questionably useful, but it's something that already exists and that has lots of weight in government / large orgs. I've started reading into it but don't have enough info to comment on RLS specifically yet. Regarding unique keys and other constraints as leakage channels, I'm inclined to think that this is partly a documentation issue. The docs can explain what is/isn't protected against. Suggest creating keys incorporating security domain identifiers so that users in different security domains can't create conflicting values. Possibly provide a mechanism to enforce that so that users can't attempt to insert/update rows with a different security identifier. Or even make it transparently part of the system's operations, an implicit extra column in PRIMARY and FOREIGN keys on RLS-enabled tables. What I'm more worried about re the covert uniqueness issue is that any solution might run the risk of creating situations where changes in access rights can make previously valid data in tables invalid. If two users A and B can't see each other's data and create the same values for a key, then B is given the rights to see A's data ... those unique values now have duplicates. So: I do think we need to step back a little when it comes to covert channel attacks and define what we do/don't defend against. What about timing attacks - do we need to make sure we don't leak information about the number of RLS rows via scan durations? Make everything constant-time? Yick. Crypto systems have a hard enough time getting this stuff right, and I just think we say we don't defend against timing attacks. If someone wants to mess around with adding random sleeps in an executor hook, well, that's their pain to deal with. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers