All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.