On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 04/14/2015 05:42 AM, Robert Haas wrote: > >> On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinn...@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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
