linux-kernel - Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 25 Jan 2015 13:24:32 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Richard Weinberger <richard.weinberger@...il.com>
CC:	Pádraig Brady <P@...igbrady.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	Michal Marek <mmarek@...e.cz>,
	David Howells <dhowells@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] modsign: use shred to overwrite the private key before
 deleting it

Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
> On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler <holler@...oftware.de> wrote:
>> Now, after I ended up into flaming a lot (sorry again, but this topic made
>> me angry for so long and I had to spent too much time to get rid of unwanted
>> content and answering other peoples question in regard to that topic), I
>> should offer something more useful.
>>
>> So I've written down in some short words, how I think it could be done:
>>
>> First offer a syscall named sunlink() (or whatever name) which fails if it
>> can't overwrite or securely trim the contents of a file before deleting it.
>>
>> That could be done like this:
>>
>> (1) If it's a SSD or MMC without offering "Secure Trim" fail.
>> (2) If it's a plain FLASH or conventional harddisk where writing a block
>> means that block will be overwritten or if it's a SSD or MMC with "Secure
>> Trim) go on with
>> (3) Identify the blocks which contain the file contents (should be doable by
>> using the same mechanisms used to read and write a file)
>> (4) Mark the file as deleted
>> (5) Overwrite or securely trim blocks which can be deleted completely
>> (6) Build new blocks for blocks which can only partly deleted because they
>> contain information still used by the FS or other files
>> (7) Instruct the FS to us the new blocks instead of the old ones
>> (8) Overwrite or securely trim the old blocks which previously contained
>> partly information of other stuff.
>>
>> Afterwards use that new syscall in shred.
>>
>> Of course, this is just a totally simplified instruction in regard to how
>> complicated filesystems have become, but I think there isn't any black magic
>> involved in offering the user a simple way to really delete files.
>
> Or add support for the "s" chattr to major filesystems.
>
And change the manpage for the 's' attribute to change the "overwriting 
with zero" with some other wording.

But thanks for the hint. I wasn't aware of that bit (maybe because it's 
still useless on most filesystems).

But the above silly instruction might still help in implementing support 
for the 's' attribute.

Also I wonder what happens if you delete a file with such an attribute 
on e.g. an SSD. I assume the user just gets a false positive that the 
file is deleted, which isn't much different to what nowadays happens and 
doesn't therefor really help.

So maybe shred should first set the 's' attribute before calling unlink 
on that file (if it doesn't already do it). I will look at it and send a 
patch if necessary. It's at least a small bit where I can help. ;)

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/