On Thu, Jul 9, 2015 at 10:05 PM, Michael Paquier
wrote:
> On Wed, Jul 8, 2015 at 11:33 AM, Fujii Masao wrote:
>> ISTM that one our consensus is to make wal_compression SUSET
>> as the first step whatever approach we adopt for the risk in question
>> later. So, barring any objection, I will commit
On Wed, Jul 8, 2015 at 11:33 AM, Fujii Masao wrote:
> ISTM that one our consensus is to make wal_compression SUSET
> as the first step whatever approach we adopt for the risk in question
> later. So, barring any objection, I will commit the attached patch
> and change the context to PGC_SUSET.
Tha
On Tue, Jul 7, 2015 at 11:34 PM, Stephen Frost wrote:
> * Fujii Masao (masao.fu...@gmail.com) wrote:
>> On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost wrote:
>> > I'm not following. If we don't want the information to be available to
>> > everyone then we need to limit it, and right now the only
On Wed, Jul 8, 2015 at 2:40 AM, Heikki Linnakangas wrote:
> On 07/07/2015 07:31 PM, Fujii Masao wrote:
>>
>> Or another crazy idea is to append "random length" dummy data into
>> compressed FPW. Which would make it really hard for an attacker to
>> guess the information from WAL location.
>
>
> It
On Tue, Jul 7, 2015 at 2:29 PM, Stephen Frost wrote:
>> Or another crazy idea is to append "random length" dummy data into
>> compressed FPW. Which would make it really hard for an attacker to
>> guess the information from WAL location. Even if this option is enabled,
>> you can still have the per
On 07/07/2015 07:31 PM, Fujii Masao wrote:
Or another crazy idea is to append "random length" dummy data into
compressed FPW. Which would make it really hard for an attacker to
guess the information from WAL location.
It makes the signal more noisy, but you can still mount the same attack
if y
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost wrote:
> > I'd rather we hide it now, to allow FPW compression to be enabled for
> > everyone, except those few environments where it ends up making things
> > worse, and then provide the monitoring role
On Tue, Jul 7, 2015 at 2:24 PM, Stephen Frost wrote:
> * Claudio Freire (klaussfre...@gmail.com) wrote:
>> On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote:
>> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> >> On 07/07/2015 04:31 PM, Stephen Frost wrote:
>> >> >The alternative is to have
* Claudio Freire (klaussfre...@gmail.com) wrote:
> On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> >> On 07/07/2015 04:31 PM, Stephen Frost wrote:
> >> >The alternative is to have monitoring tools which are running as
> >> >superuser, which
On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 07/07/2015 04:31 PM, Stephen Frost wrote:
>> >The alternative is to have monitoring tools which are running as
>> >superuser, which, in my view at least, is far worse.
>>
>> Or don't enable
On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 07/07/2015 04:31 PM, Stephen Frost wrote:
>> >The alternative is to have monitoring tools which are running as
>> >superuser, which, in my view at least, is far worse.
>>
>> Or don't enable
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/07/2015 04:31 PM, Stephen Frost wrote:
> >The alternative is to have monitoring tools which are running as
> >superuser, which, in my view at least, is far worse.
>
> Or don't enable fpw_compression for tables where the information
> leak is a
On 07/07/2015 04:31 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 07/07/2015 04:15 PM, Stephen Frost wrote:
* Fujii Masao (masao.fu...@gmail.com) wrote:
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
wrote:
+ the compression ratio of a full page image gi
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost wrote:
> > I'm not following. If we don't want the information to be available to
> > everyone then we need to limit it, and right now the only way to do that
> > is to restrict it to superuser because w
On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> On 07/07/2015 04:15 PM, Stephen Frost wrote:
>> >* Fujii Masao (masao.fu...@gmail.com) wrote:
>> >>On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
>> >> wrote:
>> >>>+ the compression
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/07/2015 04:15 PM, Stephen Frost wrote:
> >* Fujii Masao (masao.fu...@gmail.com) wrote:
> >>On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
> >> wrote:
> >>>+ the compression ratio of a full page image gives a hint of what
> >>>is
> >>>
On 07/07/2015 04:15 PM, Stephen Frost wrote:
* Fujii Masao (masao.fu...@gmail.com) wrote:
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
wrote:
+ the compression ratio of a full page image gives a hint of what is
+ the existing data of this page. Tables that contain sensitiv
* Fujii Masao (masao.fu...@gmail.com) wrote:
> On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
> wrote:
> > On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> > wrote:
> >> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
> >> wrote:
> >>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
> >
On Sat, May 30, 2015 at 4:58 PM, Michael Paquier
wrote:
> On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
> wrote:
>> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
>> wrote:
>>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>>> wrote:
On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wro
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> wrote:
>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>> wrote:
>>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> wrote:
>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>> wrote:
>>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
> wrote:
>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
>>> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
1) Doc patch to mention that it is possible that compression
On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
>> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
>>> 1) Doc patch to mention that it is possible that compression can give
>>> hints to attackers when working on sensible fields
On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
>> 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
On 04/10/2015 05:17 AM, Robert Haas wrote:
I bet that there are at least 1000 covert channel attacks that are
more practically exploitable than this. When this is anywhere near
the top of the list of things to worry about, I recommend we throw a
huge party and then fly home in our faster-than-lig
On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 11:10 AM, Fujii Masao wrote:
>> On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander
>> wrote:
>>> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas wrote:
On 04/14/2015 05:42 AM, Robert Haas wrote:
>>>
On Wed, Apr 15, 2015 at 12:15 AM, Stephen Frost wrote:
> We need a proper "hardening"
> guide anyway, this would just need to be included in that documentation.
+1. I am sure that many users would like a hardening manual in the
official documentation.
--
Michael
--
Sent via pgsql-hackers maili
On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
> 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.
On Wed, Apr 15, 2015 at 11:10 AM, Fujii Masao wrote:
> On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander wrote:
>> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas wrote:
>>>
>>> On 04/14/2015 05:42 AM, Robert Haas wrote:
On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas
wro
On Wed, Apr 15, 2015 at 12:00 AM, Magnus Hagander wrote:
> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas wrote:
>>
>> On 04/14/2015 05:42 AM, Robert Haas wrote:
>>>
>>> On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas
>>> wrote:
As to RLS - yeah, that's where I think a lot of
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas wrote:
> > 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.
I
On Tue, Apr 14, 2015 at 4:50 PM, Heikki Linnakangas wrote:
> On 04/14/2015 05:42 AM, Robert Haas wrote:
>
>> On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas
>> wrote:
>>
>>> As to RLS - yeah, that's where I think a lot of the possible covert
>>>
>> channel attacks are. But it doesn't have t
On 04/14/2015 05:42 AM, Robert Haas wrote:
On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas wrote:
Care to name some? This is certainly quite cumbersome to exploit, but it's
doable.
We've talked a lot about covert channels and timing attacks on RLS, but this
makes me more worried because yo
On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas wrote:
> Care to name some? This is certainly quite cumbersome to exploit, but it's
> doable.
>
> We've talked a lot about covert channels and timing attacks on RLS, but this
> makes me more worried because you can attack passwords stored in pg_a
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 04/10/2015 05:17 AM, Robert Haas wrote:
> >On Apr 9, 2015, at 8:51 PM, Heikki Linnakangas wrote:
> >>What should we do about this?
> >
> >I bet that there are at least 1000 covert channel attacks that are more
> >practically exploitable than this
On Thu, Apr 9, 2015 at 8:51 PM, Heikki Linnakangas wrote:
>
> All in all, this is a bit clumsy and very time-consuming to pull off in
practice, but it's possible at least if the conditions are just right.
>
> What should we do about this? Make it configurable on a per-table basis?
I think making
On Mon, Apr 13, 2015 at 9:38 AM, Heikki Linnakangas wrote:
> On 04/10/2015 05:17 AM, Robert Haas wrote:
>>
>> On Apr 9, 2015, at 8:51 PM, Heikki Linnakangas wrote:
>>>
>>> What should we do about this?
>>
>>
>> I bet that there are at least 1000 covert channel attacks that are more
>> practically
On 04/10/2015 05:17 AM, Robert Haas wrote:
On Apr 9, 2015, at 8:51 PM, Heikki Linnakangas wrote:
What should we do about this?
I bet that there are at least 1000 covert channel attacks that are more
practically exploitable than this.
Care to name some? This is certainly quite cumbersome to
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 04/09/2015 06:28 PM, Stephen Frost wrote:
> >* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> >>What should we do about this? Make it configurable on a per-table
> >>basis? Disable FPW compression on system tables? Disable FPW on
> >>tables you don'
On 04/09/2015 06:28 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
What should we do about this? Make it configurable on a per-table
basis? Disable FPW compression on system tables? Disable FPW on
tables you don't have SELECT access to? Add a warning to the docs?
REVOKE
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> What should we do about this? Make it configurable on a per-table
> basis? Disable FPW compression on system tables? Disable FPW on
> tables you don't have SELECT access to? Add a warning to the docs?
REVOKE EXECUTE ON FUNCTION pg_current_xlog_insert
Now that we have compression of full-page images in WAL, it can be used
to leak sensitive information you're not supposed to see. Somewhat
similar to the recent BREACH and CRIME attacks on SSL, if you can insert
into a table, the compression ratio gives you a hint of how similar the
existing da
42 matches
Mail list logo
