Re: Shared system resources - Mailing list pgsql-general
| From | oleg yusim |
|---|---|
| Subject | Re: Shared system resources |
| Date | |
| Msg-id | CAKd4e_Fj2_PDx=XemXihj5Xm+EY-oJ+H2b7ZcP2BOyfwHvaCoQ@mail.gmail.com Whole thread Raw |
| In response to | Re: Shared system resources (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Responses |
Re: Shared system resources
(John R Pierce <pierce@hogranch.com>)
|
| List | pgsql-general |
Jim,
Help me out with this statement:
"There's tons of raw data stored in the shared memory segment, and some of that can be copied to process local memory at any time. If they OS doesn't secure that adequately there's certainly nothing that Postgres or any other database can do about it."
To my knowledge, many databases are using what called TDE to encrypt data at rest and protect data from being accessed by attacker on host this way. Here is the reference to quick guide on it: https://www.simple-talk.com/sql/database-administration/transparent-data-encryption/
Now, when you are saying " tons of raw data stored in the shared memory segment, and some of that can be copied to process local memory at any time" what kind of memory you are referring too? Is it that files, which generally end up being protected with TDE, or is it a buffer memory, which get's used by database processes, but doesn't belong to database permanent storage?
Can you give me more details here, so I would understand the actual mapping and scale of the issue?
Thanks,
Oleg
On Wed, Dec 23, 2015 at 9:55 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 12/23/15 7:55 AM, oleg yusim wrote: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.
There's tons of raw data stored in the shared memory segment, and some of that can be copied to process local memory at any time. If they OS doesn't secure that adequately there's certainly nothing that Postgres or any other database can do about it.
As David said, by the time you're concerned about someone getting access to raw memory it's already way too late.
As for memory pages being zero'd after they are returned to the OS, that's entirely up to the OS. The only thing you could do on the Postgres side is to compile with memory debugging enabled, which will over-write any memory that's freed with a magic value. That's done to help hunt down memory access bugs, but would have the obvious side effect of obliterating any data that was in the page.
Uh, only thing is, I don't know if this is done if we're going to be returning the memory to the OS.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
pgsql-general by date: