Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data.
От | Adrian Klaver |
---|---|
Тема | Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data. |
Дата | |
Msg-id | 564CE7F3.5010609@aklaver.com обсуждение исходный текст |
Ответ на | Re: postgres zeroization of dead tuples ? i.e scrubbing dead tuples with sensitive data. ("Day, David" <dday@redcom.com>) |
Ответы |
Re: postgres zeroization of dead tuples ? i.e scrubbing
dead tuples with sensitive data.
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: