All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Richard Weinberger <richard.weinberger@gmail.com>
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:36:33 +0100	[thread overview]
Message-ID: <54C4E351.6010601@ahsoftware.de> (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:
>>
>> 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. ;)

And the manpage for chattr doesn't explain what should happen if a file 
with the 's' attrribute is changed. A reasonable answer to that is that 
the old contents, if not changed by overwriting them, should be 
deleted/zeroed too.

Regards,

Alexander Holler

  parent reply	other threads:[~2015-01-25 12:36 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
2015-01-25 12:57                               ` Alexander Holler
2015-01-25 12:36                             ` Alexander Holler [this message]
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=54C4E351.6010601@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=P@draigbrady.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=richard.weinberger@gmail.com \
    --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.