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