Re: FPW compression leaks information

On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Apr 15, 2015 at 11:10 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> 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.
>>
>> +1
>
> OK. I am fine to implement anything required here if needed, meaning
> the following:
> 1) Doc patch to mention that it is possible that compression can give
> hints to attackers when working on sensible fields that have a
> non-fixed size.

I think that this patch is enough as the first step.

> 2) Switch at relation level to control wal_compression.

ALTER TABLE SET is not allowed on system catalog like pg_authid. So should we
change it so that a user can change the flag even on system catalog? I'm afraid
that the change might cause another problem, though. Probably we can disable
the compression on every system catalogs by default. But I can imagine that
someone wants to enable the compression even on system catalog. For example,
pg_largeobject may cause lots of FPW.

> This needs to
> change XLogRecordAssemble by adding some new logic to check if a
> relation is enforcing WAL compression or not. As a reloption, there
> are three possible values: true, false and fallback to system default.
> Also, I think that we should simply extend XLogRegisterBuffer() and
> pass to it the reloption flag that is then registered in
> registered_buffer, and XLogRecordAssemble() decides with this flag if
> block is compressed or not. Do we want to add this reloption switch to
> indexes as well?

Maybe.

Regards,

-- 
Fujii Masao