On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 04/14/2015 05:42 AM, Robert Haas wrote:
On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
As to RLS - yeah, that's where I think a lot of the possible covert
channel attacks are. But it doesn't have to be RLS per se. It can be, for example, a table some of whose contents you expose via a security barrier view. It can be a security-definer function that you call and it returns some data that you don't have rights to view directly. Basically, it can be any table to which you have some access, but not complete access. Then you can use timing attacks, scrutinize EXPLAIN plans for clues, look at CTIDs, and so on.
Basically, I'm worried that it's going to be completely impractical to prevent a certain amount of information leakage when you have partial access to a table, and that in a largely-futile effort to try to prevent it, we'll end up making a whole bunch of things (like the WAL insert position) super-user only, and that this will in fact be a net reduction in security because it'll encourage people to use the superuser account more.
Perhaps that concern is ill-founded, but that's what I'm worried about.
I'm not a big fan of locking down WAL position information either. If we have to treat the current WAL position is security-sensitive information, we're doing something wrong.
But I don't want to just give up either. One option is to make this controllable on a per-table basis, as Amit suggested. Then we could always disable it for pg_authid, add a suitable warning to the docs, and let the DBA enable/disable it for other tables. It's a bit of a cop-out, but would fix the immediate problem.
I think it's a fairly narrow attack vector. As long as we document it clearly, and make it easy enough to turn it off, I think that's definitely enough. Most people will not care at all, I'm sure - but we need to cater to those that do.
I think we could probably even get away with just documenting the risk and having people turn off the compression *completely* if they care about it, but if we can do it at a table level, that's obviously a lot better.
