Re: Shared system resources

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!

On Wed, Dec 23, 2015 at 12:10 PM, oleg yusim <olegyusim(at)gmail(dot)com> wrote:

> Thank you very much George, that is exactly the piece of information I was
> missing.
>
> Oleg
>
> On Wed, Dec 23, 2015 at 10:55 AM, George Neuner <gneuner2(at)comcast(dot)net>
> wrote:
>
>> Hi Oleg,
>>
>> On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyusim(at)gmail(dot)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(at)postgresql(dot)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.