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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
