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 <olegyu...@gmail.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 <gneun...@comcast.net> > wrote: > >> Hi Oleg, >> >> On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyu...@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.
