Re: Complete data erasure - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: Complete data erasure |
Date | |
Msg-id | 20200115162238.pczmadtcth7clbxx@development Whole thread Raw |
In response to | Re: Complete data erasure (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: Complete data erasure
Re: Complete data erasure |
List | pgsql-hackers |
On Wed, Jan 15, 2020 at 10:23:22AM -0500, Stephen Frost wrote: >Greetings, > >* Tom Lane (tgl@sss.pgh.pa.us) wrote: >> "asaba.takanori@fujitsu.com" <asaba.takanori@fujitsu.com> writes: >> > I want to add the feature to erase data so that it cannot be restored >> > because it prevents attackers from stealing data from released data area. >> >> I think this is fairly pointless, unfortunately. > >I disagree- it's a feature that's been asked for multiple times and does >have value in some situations. > >> Dropping or truncating tables is as much as we can do without making >> unwarranted assumptions about the filesystem's behavior. You say >> you want to zero out the files first, but what will that accomplish >> on copy-on-write filesystems? > >What about filesystems which are not copy-on-write though? > >> Even granting that zeroing our storage files is worth something, >> it's not worth much if there are more copies of the data elsewhere. > >Backups are not our responsibility to worry about, or, at least, it'd be >an independent feature if we wanted to add something like this to >pg_basebackup, and not something the initial feature would need to worry >about. > >> And any well-run database is going to have backups, or standby servers, >> or both. There's no way for the primary node to force standbys to erase >> themselves (and it'd be a different sort of security hazard if there >> were). > >A user can't "force" PG to do anything more than we can "force" a >replica to do something, but a user can issue a request to a primary and >that primary can then pass that request along to the replica as part of >the WAL stream. > >> Also to the point: if your assumption is that an attacker has access >> to the storage medium at a sufficiently low level that they can examine >> previously-deleted files, what's stopping them from reading the data >> *before* it's deleted? > >This argument certainly doesn't make any sense- who said they had access >to the storage medium at a time before the files were deleted? What if >they only had access after the files were zero'd? When you consider the >lifetime of a storage medium, it's certainly a great deal longer than >the length of time that a given piece of sensitive data might reside on >it. > >> So I think doing anything useful in this area is a bit outside >> Postgres' remit. You'd need to be thinking at an operating-system >> or hardware level. > >I disagree entirely. If the operating system and hardware level provide >a way for this to work, which is actually rather common when you >consider that ext4 is an awful popular filesystem where this would work >just fine with nearly all traditional hardware underneath it, then we're >just blocking enabling this capability for no justifiably reason. > Not sure. I agree the goal (securely discarding data) is certainly worthwile, although I suspect it's just of many things you'd need to care about. That is, there's probably a million other things you'd need to worry about (logs, WAL, CSV files, temp files, ...), so with actually sensitive data I'd expect people to just dump/load the data into a clean system and rebuild the old one (zero drives, ...). But let's assume it makes sense - is this really the right solution? I think what I'd prefer is encryption + rotation of the keys. Which should work properly even on COW filesystems, the performance impact is kinda low and amortized etc. Of course, we're discussing built-in encryption for quite a bit of time. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: