Re: Shared system resources - Mailing list pgsql-general

From George Neuner
Subject Re: Shared system resources
Date
Msg-id qrel7bpp9q3397oacj78adlte14fmnutfs@4ax.com
Whole thread Raw
In response to Shared system resources  (oleg yusim <olegyusim@gmail.com>)
Responses Re: Shared system resources  (oleg yusim <olegyusim@gmail.com>)
Re: Shared system resources  (Andres Freund <andres@anarazel.de>)
List pgsql-general
Hi Oleg,

On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyusim@gmail.com>
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?

With recent kernels, by default there is no way for a userspace
process (even root) to dump memory.  Older kernels by default
permitted a root process unrestricted access to /dev/mem and
/dev/kmem, however in general that isn't needed and has long been
disabled by the mahor distros.  [see CONFIG_STRICT_DEVMEM].  IIRC, the
default setting was changed in 2011.

With sufficient privileges, a debugger-like process can attach and
examine the memory of a running - or just terminated - process, but it
won't have access to discarded (unmapped) memory.

The MAP_UNINITIALIZED trick, even if it works, is not a predictable
attack vector.  There is no way to ask for any *particular* VMM page -
mmap() just gives you a set of pages sufficient to cover the requested
address range ... you don't know what process those pages previously
belonged to.  Obviously there is a known algorithm for satisfying the
page requests, but the set of free pages includes both code and data
and depends on the history of system activity.  There's no guarantee
to get anything useful.

I'm not sure any of this really answers your question.
George

pgsql-general by date:

Previous
From: Alexander Franca Fernandes
Date:
Subject: Re: Huge delay to finish even having all the records inserted
Next
From: oleg yusim
Date:
Subject: Re: Shared system resources