Re: Complete data erasure

On Wed, Jan 15, 2020 at 10:23:22AM -0500, Stephen Frost wrote:
>Greetings,
>
>* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> "asaba(dot)takanori(at)fujitsu(dot)com" <asaba(dot)takanori(at)fujitsu(dot)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