From: Richard Weinberger <richard@nod.at>
To: Alexander Holler <holler@ahsoftware.de>
Cc: "Pádraig Brady" <P@draigbrady.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
"Michal Marek" <mmarek@suse.cz>,
"David Howells" <dhowells@redhat.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it
Date: Sun, 25 Jan 2015 13:28:49 +0100 [thread overview]
Message-ID: <54C4E181.4080004@nod.at> (raw)
In-Reply-To: <54C4E080.4020507@ahsoftware.de>
Am 25.01.2015 um 13:24 schrieb Alexander Holler:
> Am 25.01.2015 um 13:08 schrieb Richard Weinberger:
>> On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler <holler@ahsoftware.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.
The implementation will be challenging. Especially for modern filesytems like btrfs or f2fs which are copy-on-write based.
Thanks,
//richard
next prev parent reply other threads:[~2015-01-25 12:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 1:20 [PATCH] modsign: provide option to automatically delete the key after modules were installed Alexander Holler
2015-01-23 9:24 ` Michal Marek
2015-01-23 9:39 ` Alexander Holler
2015-01-23 10:15 ` Alexander Holler
2015-01-23 10:55 ` Michal Marek
2015-01-23 11:43 ` Alexander Holler
2015-01-23 11:54 ` Alexander Holler
2015-01-23 12:34 ` Alexander Holler
2015-01-23 18:26 ` Alexander Holler
2015-01-23 12:56 ` David Howells
2015-01-23 13:27 ` Alexander Holler
2015-01-23 13:35 ` Alexander Holler
2015-01-23 21:57 ` [PATCH] modsign: overwrite keys with zero before deleting them Alexander Holler
2015-01-23 22:06 ` Richard Weinberger
2015-01-23 22:16 ` Alexander Holler
2015-01-23 23:58 ` David Howells
2015-01-24 0:13 ` Alexander Holler
2015-01-24 1:27 ` Pádraig Brady
2015-01-24 10:45 ` [PATCH v2] modsign: use shred to overwrite the private key before deleting it Alexander Holler
2015-01-24 11:37 ` Alexander Holler
2015-01-24 12:09 ` Alexander Holler
2015-01-24 12:29 ` Alexander Holler
2015-01-25 2:13 ` Pádraig Brady
2015-01-25 2:43 ` Alexander Holler
2015-01-25 10:32 ` Alexander Holler
2015-01-25 10:57 ` Alexander Holler
2015-01-25 11:42 ` Alexander Holler
2015-01-25 12:04 ` Alexander Holler
2015-01-25 12:08 ` Richard Weinberger
2015-01-25 12:24 ` Alexander Holler
2015-01-25 12:28 ` Richard Weinberger [this message]
2015-01-25 12:57 ` Alexander Holler
2015-01-25 12:36 ` Alexander Holler
2015-01-25 13:46 ` Alexander Holler
2015-01-29 22:39 ` Alexander Holler
2015-07-18 21:56 ` [PATCH] modsign: provide option to automatically delete the key after modules were installed Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C4E181.4080004@nod.at \
--to=richard@nod.at \
--cc=P@draigbrady.com \
--cc=dhowells@redhat.com \
--cc=holler@ahsoftware.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome