Re: Shared system resources - Mailing list pgsql-general
Oleg,
As others have pointed out, worrying about someone accessing database shared memory is like worrying about an asteroid striking the earth and wiping out all life.
It's a one in a billion chance compared to other security violations that can occur.
You are better off concentrating on proper O/S security and user/table permissions. That is how to implement database security!
As others have pointed out, worrying about someone accessing database shared memory is like worrying about an asteroid striking the earth and wiping out all life.
It's a one in a billion chance compared to other security violations that can occur.
You are better off concentrating on proper O/S security and user/table permissions. That is how to implement database security!
On Wed, Dec 23, 2015 at 12:10 PM, oleg yusim <olegyusim@gmail.com> wrote:
Thank you very much George, that is exactly the piece of information I was missing.OlegOn Wed, Dec 23, 2015 at 10:55 AM, George Neuner <gneuner2@comcast.net> wrote: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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Melvin Davidson
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
pgsql-general by date: