Stephen Frost <sfr...@snowman.net> writes:
> We have issues with covert channels even without RLS though and holding
> up RLS because it doesn't fix all the covert channels isn't sensible.
I think it's entirely sensible to question whether we should reject (not
"hold up") RLS if it has major covert-channel problems.
The scenario I'm worried about is where somebody says "hey, Postgres has
RLS now, I can rely on that to hide my sooper sekrit data from other users
in the same database", and later they have a security breach through some
covert-channel attack. Are they going to blame themselves? No, they're
gonna blame Postgres. Or consider the case where some bozo publishes
a method for such an attack and uses it to badmouth us as insecure.
I don't think we need the headaches that will result from promising
(or at least appearing to promise) something we can't deliver. Nor am
I convinced that we're really doing users any favors by providing such a
feature. They'd be *far* better advised to put their critical data in a
separate database.
In short, "we can check some check-box" is a really, really bad reason
to accept a security-related feature. If we're going to put up with
all the downsides of RLS, I want the end result to be something that's
actually secure, not something that gives the illusion of security.
And right now, I do not believe we can get past the illusion stage,
ever (certainly not in a release or two).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
