Re: Shared system resources - Mailing list pgsql-general

From oleg yusim
Subject Re: Shared system resources
Date
Msg-id CAKd4e_E0t0xetzbWz_zrB9XRz9QAJ+mFSpBc1F-PgEHRBHf61w@mail.gmail.com
Whole thread Raw
In response to Re: Shared system resources  (David Wilson <dw+pg@hmmz.org>)
Responses Re: Shared system resources  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-general
Sure David. For simplicity of modeling here, let's assume raw database data was encrypted and the only possibility for attacker to get something from raw data is to go and dig into sessions leftovers. Now, with that has been said, do you happen to know what information actually gets stored during the session into memory, reserved by session process? I'm trying to determine, basically, does it even worth a talk - maybe there is nothing at all valuable.

Thanks,

Oleg

On Wed, Dec 23, 2015 at 7:41 AM, David Wilson <dw+pg@hmmz.org> wrote:
On Wed, Dec 23, 2015 at 07:07:31AM -0600, oleg yusim wrote:

> May we run into situation, when attacker dumps memory and analyses it
> for valuable content, instead of reserving it for own process, where
> it would be zeroed? My understanding, it is a possibility. Does kernel
> have any safeguard against it?

Sure it might be possible, but they would not have much useful
information about which old processes the pages belonged to, and
besides, they could most likely simply dump memory of a connected client
in this case, or indeed just examine the filesystem or cache to get at
the raw PG database files.

Once someone has this level of access to the system it's not really
useful to model threats much further.

One minor correction from my first mail: MAP_UNINITIALIZED is indeed
accessible to non-root, but as George mentions only when a non-default
kernel parameter has been enabled.


David

pgsql-general by date:

Previous
From: David Wilson
Date:
Subject: Re: Shared system resources
Next
From: Adrian Klaver
Date:
Subject: Re: Transfer db from one port to another