On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander <mag...@hagander.net> wrote: > 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.
+1 Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
