Re: FPW compression leaks information - Mailing list pgsql-hackers

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.
2) Switch at relation level to control wal_compression. 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? Or only tables? For indexes things will get heavier
as we would need to add a parameter for all the index types.
Regards,
-- 
Michael