Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.

-----Original Message-----
From: Adrian Klaver [mailto:adrian.klaver@aklaver.com]
Sent: Thursday, November 19, 2015 10:32 AM
To: Day, David; pgsql-general@postgresql.org
Subject: Re: [GENERAL] postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.

On 11/19/2015 07:01 AM, Day, David wrote:
>
>
> -----Original Message-----
> From: Adrian Klaver [mailto:adrian.klaver@aklaver.com]
> Sent: Wednesday, November 18, 2015 4:05 PM
> To: Day, David; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.
>
> On 11/18/2015 12:57 PM, Day, David wrote:
>>
>> -----Original Message-----
>> From: Adrian Klaver [mailto:adrian.klaver@aklaver.com]
>> Sent: Wednesday, November 18, 2015 3:47 PM
>> To: Day, David; pgsql-general@postgresql.org
>> Subject: Re: [GENERAL] postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.
>>
>> On 11/18/2015 11:45 AM, Day, David wrote:
>>> Hi,
>>>
>>> One of my co-workers came out of a NIST cyber-security type meeting
>>> today and asked me to delve into postgres and zeroization.
>>>
>>> I am casually aware of mvcc issues and vacuuming
>>>
>>> I believe the   concern,  based on my current understanding  of postgres
>>> inner workings,  is  that when a dead tuple is reclaimed by vacuuming:
>>>     Is that reclaimed space initialized in some fashion that would
>>> shred any sensitive data that was formerly there to any  inspection
>>> by the subsequent owner of  that disk page ? ( zeroization )
>>
>> Got to thinking, are you talking about a physical machine or a VM/container on shared hosting? If the latter then it
isa more generic problem of detritus left behind between creations of virtual instances or cross talk on shared
storage.
>>
>>>
>>> Not sure that is the exact question to ask but hopefully you get a
>>> feel for the requirement is  not to  leave any sensitive data laying
>>> about for
>>>
>>> recovery by a hacker,  or at least minimize the places it could be
>>> obtained without actually being able to log into postgres or having
>>> raw disk access privileges.
>>>
>>> Thanks for any comments/instruction/links on the matter.
>>>
>>> Regards
>>>
>>> Dave Day
>>>
>>
>>
>> --
>> Adrian Klaver
>> adrian.klaver@aklaver.com
>>
>> In some instances this would be a vm instance on a hosted machine in other cases a actual physical machine.
>>
>> Thank you all for the feedback.
>>
>>
>> All good points.  I am not sure what the manner of attack/hack is until I get some further feedback out of the
meetingparticipants.  I suspect it would be to the blocks pages released by postgres following a vacuum full. 
>> How you determine what those pages blocks were I am not sure but suspect there is probably a way.
>> When I get some more detail on the standard and exact requirement I will repost with that info.
>
> Yes, a detailed problem description would be helpful.
>
>>
>>
>> Again thanks
>>
>>
>>
>> Dave Day
>>
>>
>>
>>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
>
> Good Day,
>
> The specification that was under discussion was "collaborative Protection Profile for Network Devices"
> https://www.niap-ccevs.org/pp/cpp_nd_v1.0.pdf   Section 5.4.1.3 FCS_CKM.4 Crypotographic Key Destruction.
>
>
> The interpreted concern with respect to postgress includes  its released non-volatile and volatile memory.
>
> In the non-volatile case I believe this would amount to the vacuum -full scenario as commented on by David Johnston
andMelvin Davidson.  I have not looked at Tom Lanes source reference bufpage.c to see if that could be customized in
theshort term to sanitize the page being returned. 
>
> In the volatile memory case it would seem to include any memory used by postgres that might have included sensitive
dataand is at some point freed and therefore available in the general pool for allocation  and subject to  inspection
bythe next user. 
> Perhaps there is a common routine in the source that could perform such a job ?
>
> We are still digesting the specification and may find allowances given other security measures.

So what are you working on?

The document you link to starts with this:
"
Examples of network devices that are covered by requirements in this cPP include routers, firewalls, VPN gateways,
IDSs,and switches. ..." 

So embedded devices. Not sure how prevalent Postgres is in that area.

Also the subsection you refer to seems to be talking only about memory, not storage which is where VACUUM FULL works.
Thatmay be an overly fine distinction, but one that can be made. 


>
> Appreciate everyone's feedback.  This is perhaps a matter that can feed into future OS ( FreeBSD ) and/or Postgress
development.
>
>
> Regards
>
>
> Dave Day
>
>
>
>
>
>
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

Adrian

Our app/development is a softswitch, (VoIP), and is considered a network appliance.
Postgres in general has been a joy to learn and aside from a a hiccup with plperl and FreeBSD (9.8)
that the discussion board helped me resolve some time ago, dependable and problem free.

Dave