mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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