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
