Re: FPW compression leaks information

On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>
>> On 04/14/2015 05:42 AM, Robert Haas wrote:
>>>
>>> On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)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