Re: Complete data erasure

Hello, Asaba-san.

At Wed, 15 Jan 2020 01:31:44 +0000, "asaba(dot)takanori(at)fujitsu(dot)com" <asaba(dot)takanori(at)fujitsu(dot)com> wrote in
> Hello hackers,
>
> 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.
>
> - Background
> International security policies require that above threat is taken measures.
> It is "Base Protection Profile for Database Management Systems Version 2.12 (DBMS PP)" [1] based on iso 15408.
> If the security is improved, it will be more likely to be adopted by security-conscious procurers such as public agencies.
>
> - Feature
> This feature erases data area just before it is returned to the OS (-Y´erase¡ means that overwrite data area to hide its contents here) -A
> because there is a risk that the data will be restored by attackers if it is returned to the OS without being overwritten.
> The erase timing is when DROP, VACUUM, TRUNCATE, etc. are executed.
> I want users to be able to customize the erasure method for their security policies.

shred(1) or wipe(1) doesn't seem to contribute to the objective on
journaled or copy-on-write file systems. I'm not sure, but maybe the
same can be true for read-modify-write devices like SSD. I'm not sure
about SDelete, but anyway replacing unlink() with something like
'system("shred")' leads to siginificant performance degradation.

man 1 wipe says (https://linux.die.net/man/1/wipe) : (shred has a
similar note.)

> NOTE ABOUT JOURNALING FILESYSTEMS AND SOME RECOMMENDATIONS (JUNE 2004)
> Journaling filesystems (such as Ext3 or ReiserFS) are now being used
> by default by most Linux distributions. No secure deletion program
> that does filesystem-level calls can sanitize files on such
> filesystems, because sensitive data and metadata can be written to the
> journal, which cannot be readily accessed. Per-file secure deletion is
> better implemented in the operating system.

WAL files contain copies of such sensitive information, which is not
covered by the proposal. Also temporary files are not. If the system
doesn't want not to be recoverable after corruption, it must copy such
WAL files to archive.

Currently there's a discussion on transparent data encyryption
covering the all of the above cases on and off of this mailing list.
It is different from device-level encryption mentioned in the man
page. Doesn't that fit the requirement?

https://www.postgresql.org/message-id/CALS%2BJ3-57cL%3Djz_eT9uxiLa8CAh5BE3-HcQvXQBz0ScMjag4Zg%40mail.gmail.com

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center