[PATCH] modsign: provide option to automatically delete the key after modules were installed

[PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

I usually throw away (delete) the key used to sign modules after having
called make -jN (b)zImage modules && make -jN modules_install. Because I've
got bored to always have to type rm signing_key.* afterwards, I've build
this patch some time ago.
As I'm not eager anymore to publish kernel patches, it rested in my private
chest of patches until I've seen the keynote of Linux.conf.au 2015. It made
me aware that this patch might have a chance to become included. ;)

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
 Makefile     |  7 +++++++
 init/Kconfig | 12 ++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/Makefile b/Makefile
index fb93350..95e07ca 100644
--- a/Makefile
+++ b/Makefile
@@ -1129,6 +1129,13 @@ _modinst_:
 	@cp -f $(objtree)/modules.order $(MODLIB)/
 	@cp -f $(objtree)/modules.builtin $(MODLIB)/
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
+ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
+	@echo "###"
+	@echo "### Deleting key used to sign modules."
+	@echo "###"
+	@rm ./signing_key.priv
+	@rm ./signing_key.x509
+endif
 
 # This depmod is only for convenience to give the initial
 # boot a modules.dep even before / is mounted read-write.  However the
diff --git a/init/Kconfig b/init/Kconfig
index 9afb971..f29304e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1884,6 +1884,18 @@ config MODULE_SIG_ALL
 	  Sign all modules during make modules_install. Without this option,
 	  modules must be signed manually, using the scripts/sign-file tool.
 
+config MODULE_SIG_THROW_AWAY
+	bool "Automatically delete the key after modules were installed"
+	default n
+	depends on MODULE_SIG_ALL
+	help
+	  Delete the key used to sign modules after modules were installed.
+	  Be aware of the consequences. The downside is that you  won't be
+	  able to build any module for a (maybe running) kernel, but will
+	  have to rebuild the kernel and all modules in order to add or modify
+	  a module. The upside is that you don't have to secure the key in
+	  order to keep a running kernel safe from unwanted modules.
+
 comment "Do not forget to sign required modules with scripts/sign-file"
 	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
 
-- 
2.0.5

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Michal Marek]

On 2015-01-23 02:20, Alexander Holler wrote:
> I usually throw away (delete) the key used to sign modules after having
> called make -jN (b)zImage modules && make -jN modules_install. Because I've
> got bored to always have to type rm signing_key.* afterwards, I've build
> this patch some time ago.
> As I'm not eager anymore to publish kernel patches, it rested in my private
> chest of patches until I've seen the keynote of Linux.conf.au 2015. It made
> me aware that this patch might have a chance to become included. ;)
> 
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
>  Makefile     |  7 +++++++
>  init/Kconfig | 12 ++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index fb93350..95e07ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1129,6 +1129,13 @@ _modinst_:
>  	@cp -f $(objtree)/modules.order $(MODLIB)/
>  	@cp -f $(objtree)/modules.builtin $(MODLIB)/
>  	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
> +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
> +	@echo "###"
> +	@echo "### Deleting key used to sign modules."
> +	@echo "###"

Use @$(kecho) "..." to suppress output with make -s


> +	@rm ./signing_key.priv
> +	@rm ./signing_key.x509

Why do you need to delete the certificate?

Michal

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 10:24 schrieb Michal Marek:

>> +	@rm ./signing_key.priv
>> +	@rm ./signing_key.x509
> 
> Why do you need to delete the certificate?

No special reason.

I'm just not sure (and too lazy to look it up) if it might contain the
private key too (like it's possible in pem files), so I've deleted it too.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 10:39 schrieb Alexander Holler:
> Am 23.01.2015 um 10:24 schrieb Michal Marek:
>
>>> +	@rm ./signing_key.priv
>>> +	@rm ./signing_key.x509
>>
>> Why do you need to delete the certificate?
>
> No special reason.
>
> I'm just not sure (and too lazy to look it up) if it might contain the
> private key too (like it's possible in pem files), so I've deleted it too.

Or in other words, while .priv leads me to the educated guess that it 
contains the private key, .x509 doesn't give me an obvious indication 
what it contains.

If someone assures me that .x509 doesn't contain the private key 
necessary to sign the modules, I'll send a v2 of the patch.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Michal Marek]

On 2015-01-23 11:15, Alexander Holler wrote:
> Am 23.01.2015 um 10:39 schrieb Alexander Holler:
>> Am 23.01.2015 um 10:24 schrieb Michal Marek:
>>
>>>> +	@rm ./signing_key.priv
>>>> +	@rm ./signing_key.x509
>>>
>>> Why do you need to delete the certificate?
>>
>> No special reason.
>>
>> I'm just not sure (and too lazy to look it up) if it might contain the
>> private key too (like it's possible in pem files), so I've deleted it too.
> 
> Or in other words, while .priv leads me to the educated guess that it 
> contains the private key, .x509 doesn't give me an obvious indication 
> what it contains.
> 
> If someone assures me that .x509 doesn't contain the private key 
> necessary to sign the modules, I'll send a v2 of the patch.

The .x509 file contains a certificate signed by the private key, but not
the private key. With some scripting, it can be used to verify the
module signatures.

Michal

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 11:55 schrieb Michal Marek:
> On 2015-01-23 11:15, Alexander Holler wrote:
>> Am 23.01.2015 um 10:39 schrieb Alexander Holler:
>>> Am 23.01.2015 um 10:24 schrieb Michal Marek:
>>>
>>>>> +	@rm ./signing_key.priv
>>>>> +	@rm ./signing_key.x509
>>>>
>>>> Why do you need to delete the certificate?
>>>
>>> No special reason.
>>>
>>> I'm just not sure (and too lazy to look it up) if it might contain the
>>> private key too (like it's possible in pem files), so I've deleted it too.
>>
>> Or in other words, while .priv leads me to the educated guess that it
>> contains the private key, .x509 doesn't give me an obvious indication
>> what it contains.
>>
>> If someone assures me that .x509 doesn't contain the private key
>> necessary to sign the modules, I'll send a v2 of the patch.
>
> The .x509 file contains a certificate signed by the private key, but not
> the private key. With some scripting, it can be used to verify the
> module signatures.


Assuming that doesn't change (hopefully), I'll send v2 in a few minutes 
(it just compiles in order to test it). Thanks for assuring me that 
.x509 does not and will not contain the private key.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 12:43 schrieb Alexander Holler:
> Am 23.01.2015 um 11:55 schrieb Michal Marek:

>> The .x509 file contains a certificate signed by the private key, but not
>> the private key. With some scripting, it can be used to verify the
>> module signatures.
>
>
> Assuming that doesn't change (hopefully), I'll send v2 in a few minutes
> (it just compiles in order to test it). Thanks for assuring me that
> .x509 does not and will not contain the private key.

I'm happy I did that. Just deleting the private key currently doesn't 
work. A subsequent make fails:

-----------------------------
(...)
###
### Deleting the private key used to sign modules.
###
   DEPMOD  3.18.3-00076-ga775cc9
[root@krabat linux]# less signing_key.x509
"signing_key.x509" may be a binary file.  See it anyway?
[root@krabat linux]# make -j4 bzImage modules && make -j4 modules_install
   CHK     include/config/kernel.release
   CHK     include/generated/uapi/linux/version.h
   CHK     include/generated/utsrelease.h
   CALL    scripts/checksyscalls.sh
   CHK     include/generated/compile.h
X.509 certificate list changed
   CHK     kernel/config_data.h
   CERTS   kernel/x509_certificate_list
   - Including cert signing_key.x509
   AS      kernel/system_certificates.o
   LD      kernel/built-in.o
   LINK    vmlinux
   LD      vmlinux.o
   MODPOST vmlinux.o
   GEN     .version
   CHK     include/generated/compile.h
   UPD     include/generated/compile.h
   CC      init/version.o
   LD      init/built-in.o
   KSYM    .tmp_kallsyms1.o
   KSYM    .tmp_kallsyms2.o
   LD      vmlinux
   SORTEX  vmlinux
   SYSMAP  System.map
   Building modules, stage 2.
   VOFFSET arch/x86/boot/voffset.h
   CC      arch/x86/boot/version.o
   OBJCOPY arch/x86/boot/compressed/vmlinux.bin
   RELOCS  arch/x86/boot/compressed/vmlinux.relocs
   CC      arch/x86/boot/compressed/aslr.o
   LZMA    arch/x86/boot/compressed/vmlinux.bin.lzma
   MODPOST 747 modules
   MKPIGGY arch/x86/boot/compressed/piggy.S
   AS      arch/x86/boot/compressed/piggy.o
   LD      arch/x86/boot/compressed/vmlinux
   OBJCOPY arch/x86/boot/vmlinux.bin
   ZOFFSET arch/x86/boot/zoffset.h
   AS      arch/x86/boot/header.o
   LD      arch/x86/boot/setup.elf
   OBJCOPY arch/x86/boot/setup.bin
   BUILD   arch/x86/boot/bzImage
Setup is 16316 bytes (padded to 16384 bytes).
System is 3908 kB
CRC a049b366
Kernel: arch/x86/boot/bzImage is ready  (#682)
   INSTALL arch/x86/crypto/aes-x86_64.ko
   INSTALL arch/x86/crypto/blowfish-x86_64.ko
   INSTALL arch/x86/crypto/camellia-aesni-avx-x86_64.ko
   INSTALL arch/x86/crypto/aesni-intel.ko
Can't read private key
(...)
-----------------------------

Maybe that's the reason I've always deleted both files, can't remember.

I will see if I find the time and passion to change the Makefile in 
order to fix that. So you might either use my existing patch or wait if 
I will send a new one.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 12:54 schrieb Alexander Holler:
> Am 23.01.2015 um 12:43 schrieb Alexander Holler:
>> Am 23.01.2015 um 11:55 schrieb Michal Marek:
>
>>> The .x509 file contains a certificate signed by the private key, but not
>>> the private key. With some scripting, it can be used to verify the
>>> module signatures.
>>
>>
>> Assuming that doesn't change (hopefully), I'll send v2 in a few minutes
>> (it just compiles in order to test it). Thanks for assuring me that
>> .x509 does not and will not contain the private key.
>
> I'm happy I did that. Just deleting the private key currently doesn't
> work. A subsequent make fails:
>
> -----------------------------
> (...)
>    INSTALL arch/x86/crypto/aesni-intel.ko
> Can't read private key
> (...)
> -----------------------------
>
> Maybe that's the reason I've always deleted both files, can't remember.
>
> I will see if I find the time and passion to change the Makefile in
> order to fix that. So you might either use my existing patch or wait if
> I will send a new one.

Having had a look at the Makefile, I don't think I will change that. The 
reasons are:

1. I have no idea about how distro maintainers do handle their private 
and public keys used to sign modules.

2. There might be legitimate reasons to build the kernel using only the 
public key and not regenerating it because the private key doesn't exist.

3. I don't see any real reason not to delete the public key too if this 
new option is enabled. For me it's enough if the kernel is able to 
verify the modules with the embedded public key. For other usage 
scenarios one just should not use the new option.

4. With some scripting it should be possible to extract the public key 
out of an existing binary kernel. So there is no real need to change the 
already complicated build process which might make it even more complicated.

That means I'm still happy with the patch. So feel free to ignore or 
apply it.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[David Howells]

Alexander Holler <holler@ahsoftware.de> wrote:

> 1. I have no idea about how distro maintainers do handle their private and
> public keys used to sign modules.

In Fedora and RHEL, at least, we use a one-off on-the-fly generated transient
key for each rpm build.

When a kernel is built by rpmbuild, the source directory is generated afresh
and a new key created each time.  In the build farms, the kernel build tree is
simply erased, private key and all, at the conclusion of the build.

We make no effort to retain the transient private key as (1) it would require
special handling for kernel builds to avoid leaking it, (2) it might impact
non-buildfarm builds, and (3) it's more secure that no one has the private
key.

One thing that you have to be careful of with your patch is that if you turn
it on during development, this will drain the entropy pool from which you get
random numbers.

David

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 13:56 schrieb David Howells:

> One thing that you have to be careful of with your patch is that if you turn
> it on during development, this will drain the entropy pool from which you get
> random numbers.

Hmm, I wonder how often people are compiling kernels and how much one 
turn drains the entropy pool.

I would suggest to just get better in coding (and reviewing before 
compile testing) in order to not having to build kernels that often. Or 
just use a different config for development. ;)

My primary use case is just what Linus described in his keynote. I'm 
building and signing all my kernels whenever a new stable kernel 
appears, throwing away the keys away immediately afterwards.

And the patch avoids that I have to type the rm, and, even more usefull, 
it makes sure I don't forget to delete the keys, which would make 
signing the modules useless for me (as my kernel build directories (and 
thus the private keys) are usually residing on the machine the kernel is 
deployed afterwards).

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Sorry, either I type too fast or I think too slow, so here is another 
comment:

Am 23.01.2015 um 14:27 schrieb Alexander Holler:
> Am 23.01.2015 um 13:56 schrieb David Howells:
>
>> One thing that you have to be careful of with your patch is that if
>> you turn
>> it on during development, this will drain the entropy pool from which
>> you get
>> random numbers.
>
> Hmm, I wonder how often people are compiling kernels and how much one
> turn drains the entropy pool.
>
> I would suggest to just get better in coding (and reviewing before
> compile testing) in order to not having to build kernels that often. Or
> just use a different config for development. ;)
>
> My primary use case is just what Linus described in his keynote. I'm
> building and signing all my kernels whenever a new stable kernel
> appears, throwing away the keys away immediately afterwards.
>
> And the patch avoids that I have to type the rm, and, even more usefull,
> it makes sure I don't forget to delete the keys, which would make
> signing the modules useless for me (as my kernel build directories (and
> thus the private keys) are usually residing on the machine the kernel is
> deployed afterwards).

Besides that the keys are only deleted when modules_install is called. 
And that usually is only called if the kernels execution will be tested 
in real, which should offer enough time to fill the entropy pool. If the 
kernel and the modules are just build (and not installed), the keys will 
not be deleted.

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Am 23.01.2015 um 13:34 schrieb Alexander Holler:

> 4. With some scripting it should be possible to extract the public key
> out of an existing binary kernel. So there is no real need to change the
> already complicated build process which might make it even more
> complicated.

BTW: With "more complicated" I meant that it isn't just done with making 
modules_install depend on the private key. That would end up with the 
following when the public key exist but the private key doesn't:

- kernel is build including the public key
- private key (and thus the public key) will be generated newly
- modules will be installed using a key the kernel doesn't know about

So the solution to just delete both keys looks for me still like the 
most easy and thus preferable way to implement that feature with just a 
few line of changes.

Regards,

Alexander Holler

[PATCH] modsign: overwrite keys with zero before deleting them

[Alexander Holler]

This is for the more paranoid people, also it's
questionable what paranoid nowadays means.

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 7ad66de..590ff53 100644
--- a/Makefile
+++ b/Makefile
@@ -1132,7 +1132,9 @@ ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
 	@echo "###"
 	@echo "### Deleting key used to sign modules."
 	@echo "###"
+	@dd status=none if=/dev/zero of=./signing_key.priv bs=4096 count=1
 	@rm ./signing_key.priv
+	@dd status=none if=/dev/zero of=./signing_key.x509 bs=4096 count=1
 	@rm ./signing_key.x509
 endif
 
-- 
2.0.5

Re: [PATCH] modsign: overwrite keys with zero before deleting them

[Richard Weinberger]

On Fri, Jan 23, 2015 at 10:57 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> This is for the more paranoid people, also it's
> questionable what paranoid nowadays means.

Isn't this complete useless when modern filesystems like btrfs or
storage devices like SSDs are used?

> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 7ad66de..590ff53 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1132,7 +1132,9 @@ ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
>         @echo "###"
>         @echo "### Deleting key used to sign modules."
>         @echo "###"
> +       @dd status=none if=/dev/zero of=./signing_key.priv bs=4096 count=1
>         @rm ./signing_key.priv
> +       @dd status=none if=/dev/zero of=./signing_key.x509 bs=4096 count=1
>         @rm ./signing_key.x509
>  endif
>
> --
> 2.0.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks,
//richard

Re: [PATCH] modsign: overwrite keys with zero before deleting them

[Alexander Holler]

Am 23.01.2015 um 23:06 schrieb Richard Weinberger:
> On Fri, Jan 23, 2015 at 10:57 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> This is for the more paranoid people, also it's
>> questionable what paranoid nowadays means.
> 
> Isn't this complete useless when modern filesystems like btrfs or
> storage devices like SSDs are used?

On SSDs it's likely useless, unfortunately. In regard to filesystems it
depends (how knows what thay all do?). But it doesn't cost anything and
might still be worth to use on conventional harddisks with several
filesystems.

I would like to have a secure-delete for FLASH based drives, but I
assume it will need some time until someone established something like
secure-trim and a userspace utility will be available.

Regards,

Alexander Holler

Re: [PATCH] modsign: overwrite keys with zero before deleting them

[David Howells]

Alexander Holler <holler@ahsoftware.de> wrote:

> This is for the more paranoid people, also it's
> questionable what paranoid nowadays means.

shred?

David

Re: [PATCH] modsign: overwrite keys with zero before deleting them

[Alexander Holler]

Am 24.01.2015 um 00:58 schrieb David Howells:
> Alexander Holler <holler@ahsoftware.de> wrote:
> 
>> This is for the more paranoid people, also it's
>> questionable what paranoid nowadays means.
> 
> shred?

Seems to do the same like when using dd, just that it does it moultiple
times.

And according to an article I've read some years ago, overwrriting a
blocks on harddisks multiple times doesn't really make sense because
doing it just once is enough (the necessity to do it multiple times
seems to have been one of these unexplainable myths in the IT) .

So I've no idea if it's worth to use shred and have no idea if it's part
of any GNU/Linux system (seems likely as it it's part of coreutils), how
it's maintained and how long it will be available.

But if requested, I will replace that dd with shred or just feel free to
do it yourself.

Regards,

Alexander Holler

Re: [PATCH] modsign: overwrite keys with zero before deleting them

[Pádraig Brady]

On 24/01/15 00:13, Alexander Holler wrote:
> Am 24.01.2015 um 00:58 schrieb David Howells:
>> Alexander Holler <holler@ahsoftware.de> wrote:
>>
>>> This is for the more paranoid people, also it's
>>> questionable what paranoid nowadays means.
>>
>> shred?
> 
> Seems to do the same like when using dd, just that it does it moultiple
> times.
> 
> And according to an article I've read some years ago, overwrriting a
> blocks on harddisks multiple times doesn't really make sense because
> doing it just once is enough (the necessity to do it multiple times
> seems to have been one of these unexplainable myths in the IT) .
> 
> So I've no idea if it's worth to use shred and have no idea if it's part
> of any GNU/Linux system (seems likely as it it's part of coreutils), how
> it's maintained and how long it will be available.
> 
> But if requested, I will replace that dd with shred or just feel free to
> do it yourself.

shred is in the same package as dd (coreutils).
It's a bit more paranoid about syncing.
It also tries to write the exact size of the file,
and then rounded up block sizes to decrease the
chance of file system reallocation.
Agreed on the multiple writes being quite futile these days.
Generally overwriting with dd or shred etc. is only useful
at the device level rather than at the file system level.
Anyway to be slightly more paranoid and explicit you could:

  shred -n1 ./signing_key.priv

Pádraig.

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

[Alexander Holler]

This is for the more paranoid people, also it's
questionable what paranoid nowadays means.

It uses shred, in the hope it will somedays learn how to shred stuff on
FLASH based devices securely too, once that has become possible.

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7ad66de..733421b 100644
--- a/Makefile
+++ b/Makefile
@@ -1132,7 +1132,7 @@ ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
 	@echo "###"
 	@echo "### Deleting key used to sign modules."
 	@echo "###"
-	@rm ./signing_key.priv
+	@shred -n1 -u ./signing_key.priv
 	@rm ./signing_key.x509
 endif
 
-- 
2.1.0

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

[Alexander Holler]

Am 24.01.2015 um 11:45 schrieb Alexander Holler:

> It uses shred, in the hope it will somedays learn how to shred stuff on
> FLASH based devices securely too, once that has become possible.

BTW: This is a good example where technology failed to keep the needs of 
users in mind.

It should be relatively easy to make that possible: Using secure trim 
which erases blocks instead of just marking them as free, it should be 
possible without much effort for file systems to implement a secure 
unlink. An obvious name would be sunlink(2). Or does such already exist? 
I've seen secure trim already exists for some devices, but not sunlink().

Regards,

Alexander Holler

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

[Alexander Holler]

Am 24.01.2015 um 12:37 schrieb Alexander Holler:
> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>
>> It uses shred, in the hope it will somedays learn how to shred stuff on
>> FLASH based devices securely too, once that has become possible.
>
> BTW: This is a good example where technology failed to keep the needs of
> users in mind.

Failed completely.

Since ever it's a problem for people to securely delete files on storage.

Also it should be very simple to securely erase files on block based 
devices, people have to try cruel ways in the hope to get securely rid 
of files nobody else should be able to see ever again.

It's almost unbelievable how completely the IT industry (including the 
field I'm working myself: SW) failed in regard to that since 30 years or 
even more.

Regards,

Alexander Holler

>
> It should be relatively easy to make that possible: Using secure trim
> which erases blocks instead of just marking them as free, it should be
> possible without much effort for file systems to implement a secure
> unlink. An obvious name would be sunlink(2). Or does such already exist?
> I've seen secure trim already exists for some devices, but not sunlink().

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

[Alexander Holler]

Am 24.01.2015 um 13:09 schrieb Alexander Holler:
> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>
>>> It uses shred, in the hope it will somedays learn how to shred stuff on
>>> FLASH based devices securely too, once that has become possible.
>>
>> BTW: This is a good example where technology failed to keep the needs of
>> users in mind.
>
> Failed completely.
>
> Since ever it's a problem for people to securely delete files on storage.
>
> Also it should be very simple to securely erase files on block based
> devices, people have to try cruel ways in the hope to get securely rid
> of files nobody else should be able to see ever again.
>
> It's almost unbelievable how completely the IT industry (including the
> field I'm working myself: SW) failed in regard to that since 30 years or
> even more.

And it isn't such that this is a new requirement. Humans are doing such 
since thousands of years. They use fire to get rid of paper documents 
and even the old egypts were able to destroyed stuff on stones by using 
simple steps. Just the IT failed completely.

Really unbelievable.

So, sorry if anyone got bored by this mail, but I think that really has 
to be said and repeated.

Regards,

Alexander Holler

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

[Pádraig Brady]

On 24/01/15 12:29, Alexander Holler wrote:
> Am 24.01.2015 um 13:09 schrieb Alexander Holler:
>> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>>
>>>> It uses shred, in the hope it will somedays learn how to shred stuff on
>>>> FLASH based devices securely too, once that has become possible.
>>>
>>> BTW: This is a good example where technology failed to keep the needs of
>>> users in mind.
>>
>> Failed completely.
>>
>> Since ever it's a problem for people to securely delete files on storage.
>>
>> Also it should be very simple to securely erase files on block based
>> devices, people have to try cruel ways in the hope to get securely rid
>> of files nobody else should be able to see ever again.
>>
>> It's almost unbelievable how completely the IT industry (including the
>> field I'm working myself: SW) failed in regard to that since 30 years or
>> even more.
> 
> And it isn't such that this is a new requirement. Humans are doing such 
> since thousands of years. They use fire to get rid of paper documents 
> and even the old egypts were able to destroyed stuff on stones by using 
> simple steps. Just the IT failed completely.
> 
> Really unbelievable.
> 
> So, sorry if anyone got bored by this mail, but I think that really has 
> to be said and repeated.

Well not failed completely, just used a different method (encryption).

As for "shredding", that improves in effectiveness the lower you go.
I.E. it's effective for the whole file system (SSD range), or whole device.

Pádraig.

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

[Alexander Holler]

Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
> On 24/01/15 12:29, Alexander Holler wrote:
>> Am 24.01.2015 um 13:09 schrieb Alexander Holler:
>>> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>>>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>>>
>>>>> It uses shred, in the hope it will somedays learn how to shred stuff on
>>>>> FLASH based devices securely too, once that has become possible.
>>>>
>>>> BTW: This is a good example where technology failed to keep the needs of
>>>> users in mind.
>>>
>>> Failed completely.
>>>
>>> Since ever it's a problem for people to securely delete files on storage.
>>>
>>> Also it should be very simple to securely erase files on block based
>>> devices, people have to try cruel ways in the hope to get securely rid
>>> of files nobody else should be able to see ever again.
>>>
>>> It's almost unbelievable how completely the IT industry (including the
>>> field I'm working myself: SW) failed in regard to that since 30 years or
>>> even more.
>>
>> And it isn't such that this is a new requirement. Humans are doing such
>> since thousands of years. They use fire to get rid of paper documents
>> and even the old egypts were able to destroyed stuff on stones by using
>> simple steps. Just the IT failed completely.
>>
>> Really unbelievable.
>>
>> So, sorry if anyone got bored by this mail, but I think that really has
>> to be said and repeated.
>
> Well not failed completely, just used a different method (encryption).
>
> As for "shredding", that improves in effectiveness the lower you go.
> I.E. it's effective for the whole file system (SSD range), or whole device.

That's the usual broken way to go by adding another layer. And if you 
encrypt your whole device, it won't help if you want to delete one file. 
As long as the encrypted device is mounted and the blocks aren't 
overwritten, the stuff is still there. So your solution would end up with:

- mount encrypted device
- build kernel and secret key
- install kernel and secret key
- unmount encrypted device

That's almost the same as shredding a whole device just to securely 
delete one file, with the added complication that the encryption 
requires an authentication, which usually is very uncomfortable to do, 
at least if the authentication is somewhat secure.

Or what do you have in mind?

Sorry, but deleting a file such that it isn't readable anymore by anyone 
shouldn't be a complicated sequence of geek-stuff and all filesystem and 
storage designers should be ashamed that they haven't managed it in 
around 30 years to accomplish that simple goal. (imho) ;)

Regards,

Alexander Holler

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

[Alexander Holler]

Am 25.01.2015 um 03:43 schrieb Alexander Holler:
> Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
>> On 24/01/15 12:29, Alexander Holler wrote:
>>> Am 24.01.2015 um 13:09 schrieb Alexander Holler:
>>>> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>>>>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>>>>
>>>>>> It uses shred, in the hope it will somedays learn how to shred
>>>>>> stuff on
>>>>>> FLASH based devices securely too, once that has become possible.
>>>>>
>>>>> BTW: This is a good example where technology failed to keep the
>>>>> needs of
>>>>> users in mind.
>>>>
>>>> Failed completely.
>>>>
>>>> Since ever it's a problem for people to securely delete files on
>>>> storage.
>>>>
>>>> Also it should be very simple to securely erase files on block based
>>>> devices, people have to try cruel ways in the hope to get securely rid
>>>> of files nobody else should be able to see ever again.
>>>>
>>>> It's almost unbelievable how completely the IT industry (including the
>>>> field I'm working myself: SW) failed in regard to that since 30
>>>> years or
>>>> even more.
>>>
>>> And it isn't such that this is a new requirement. Humans are doing such
>>> since thousands of years. They use fire to get rid of paper documents
>>> and even the old egypts were able to destroyed stuff on stones by using
>>> simple steps. Just the IT failed completely.
>>>
>>> Really unbelievable.
>>>
>>> So, sorry if anyone got bored by this mail, but I think that really has
>>> to be said and repeated.
>>
>> Well not failed completely, just used a different method (encryption).
>>
>> As for "shredding", that improves in effectiveness the lower you go.
>> I.E. it's effective for the whole file system (SSD range), or whole
>> device.
>
> That's the usual broken way to go by adding another layer. And if you
> encrypt your whole device, it won't help if you want to delete one file.
> As long as the encrypted device is mounted and the blocks aren't
> overwritten, the stuff is still there. So your solution would end up with:
>
> - mount encrypted device
> - build kernel and secret key
> - install kernel and secret key

That's wrong, of course it should read "and signed modules".

> - unmount encrypted device
>
> That's almost the same as shredding a whole device just to securely
> delete one file, with the added complication that the encryption
> requires an authentication, which usually is very uncomfortable to do,
> at least if the authentication is somewhat secure.
>
> Or what do you have in mind?
>
> Sorry, but deleting a file such that it isn't readable anymore by anyone
> shouldn't be a complicated sequence of geek-stuff and all filesystem and
> storage designers should be ashamed that they haven't managed it in
> around 30 years to accomplish that simple goal. (imho) ;)

By the way, I still remember the time when people learned that if they 
delete a file on a FAT file system, it isn't really gone. Afterwards all 
kinds of device-shredding software and hardware appeared.

But instead of fixing that broken design, now, around 30 years later, 
this stupid and broken design is almost part of any storage and filesystem.

And even worse, because storage is nowadays often fixed to device (no 
floppy anymore you can easily destroy), it often has become almost 
impossible to really delete stuff on devices.
E.g. how do you overwrite an eMMC which is soldered, without the 
possibility to boot from something else in order to launch the shredding 
software?

So we are now at the point that the only way to keep some information 
private (forever) is to not store it on any computer.

How crazy or userfriendly is that?

Regards,

Alexander Holler

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

[Alexander Holler]

Am 25.01.2015 um 11:32 schrieb Alexander Holler:

> So we are now at the point that the only way to keep some information
> private (forever) is to not store it on any computer.

That should be written "any electronic device (including phones, 
tablets, cameras, TVs and clouds)" instead of "any computer".

>
> How crazy or userfriendly is that?
>
> Regards,
>
> Alexander Holler
>
>

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

[Alexander Holler]

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.

Regards,

Alexander Holler

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

[Alexander Holler]

Am 25.01.2015 um 12:42 schrieb Alexander Holler:
> 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)

(2a) for network devices and similiar stuff either propagate sunlink() 
down or fail
(2b) if in doubt, fail (it's better to inform the user that securely 
deleting a file failed than to go on silently without really deleting a 
file).

> (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.
>
> Regards,
>
> Alexander Holler

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

[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.

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

[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.

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

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

[Richard Weinberger]

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

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

[Alexander Holler]

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

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

[Alexander Holler]

Am 25.01.2015 um 13:28 schrieb Richard Weinberger:
> 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.

Sure. I didn't thought it's easy. A quick workaround for modern SSDs and 
similiar would be to call secure trim on all free blocks whenever shred 
is called. Would be a rather ugly workaround, but a least something 
which might be achieved in a short time frame instead of some bigger 
project like it's necessary to implement that erase as it should work 
from the beginning. Especially because that fundamental design goal of 
safelydeleting file wasn't a design goal from the beginning, which is 
the real failure.

Regards,

Alexander Holler

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

[Alexander Holler]

Am 25.01.2015 um 13:36 schrieb Alexander Holler:
> 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.

(...)

>> 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. ;)

(...)

That currently looks like a total waste of time. Grepping the kernel for 
SECRM_FL looks like this flags isn't supported (used) by any fs.

Regards,

Alexander Holler

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

[Alexander Holler]

Am 25.01.2015 um 11:32 schrieb Alexander Holler:
> Am 25.01.2015 um 03:43 schrieb Alexander Holler:
>> Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
>>> On 24/01/15 12:29, Alexander Holler wrote:
>>>> Am 24.01.2015 um 13:09 schrieb Alexander Holler:
>>>>> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>>>>>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>>>>>
>>>>>>> It uses shred, in the hope it will somedays learn how to shred
>>>>>>> stuff on
>>>>>>> FLASH based devices securely too, once that has become possible.
>>>>>>
>>>>>> BTW: This is a good example where technology failed to keep the
>>>>>> needs of
>>>>>> users in mind.
>>>>>
>>>>> Failed completely.
>>>>>
>>>>> Since ever it's a problem for people to securely delete files on
>>>>> storage.
>>>>>
>>>>> Also it should be very simple to securely erase files on block based
>>>>> devices, people have to try cruel ways in the hope to get securely rid
>>>>> of files nobody else should be able to see ever again.
>>>>>
>>>>> It's almost unbelievable how completely the IT industry (including the
>>>>> field I'm working myself: SW) failed in regard to that since 30
>>>>> years or
>>>>> even more.
>>>>
>>>> And it isn't such that this is a new requirement. Humans are doing such
>>>> since thousands of years. They use fire to get rid of paper documents
>>>> and even the old egypts were able to destroyed stuff on stones by using
>>>> simple steps. Just the IT failed completely.
>>>>
>>>> Really unbelievable.
>>>>
>>>> So, sorry if anyone got bored by this mail, but I think that really has
>>>> to be said and repeated.
>>>
>>> Well not failed completely, just used a different method (encryption).
>>>
>>> As for "shredding", that improves in effectiveness the lower you go.
>>> I.E. it's effective for the whole file system (SSD range), or whole
>>> device.
>>
>> That's the usual broken way to go by adding another layer. And if you
>> encrypt your whole device, it won't help if you want to delete one file.
>> As long as the encrypted device is mounted and the blocks aren't
>> overwritten, the stuff is still there. So your solution would end up
>> with:
>>
>> - mount encrypted device
>> - build kernel and secret key
>> - install kernel and secret key
>
> That's wrong, of course it should read "and signed modules".
>
>> - unmount encrypted device
>>
>> That's almost the same as shredding a whole device just to securely
>> delete one file, with the added complication that the encryption
>> requires an authentication, which usually is very uncomfortable to do,
>> at least if the authentication is somewhat secure.
>>
>> Or what do you have in mind?
>>
>> Sorry, but deleting a file such that it isn't readable anymore by anyone
>> shouldn't be a complicated sequence of geek-stuff and all filesystem and
>> storage designers should be ashamed that they haven't managed it in
>> around 30 years to accomplish that simple goal. (imho) ;)
>
> By the way, I still remember the time when people learned that if they
> delete a file on a FAT file system, it isn't really gone. Afterwards all
> kinds of device-shredding software and hardware appeared.
>
> But instead of fixing that broken design, now, around 30 years later,
> this stupid and broken design is almost part of any storage and filesystem.
>
> And even worse, because storage is nowadays often fixed to device (no
> floppy anymore you can easily destroy), it often has become almost
> impossible to really delete stuff on devices.
> E.g. how do you overwrite an eMMC which is soldered, without the
> possibility to boot from something else in order to launch the shredding
> software?
>
> So we are now at the point that the only way to keep some information
> private (forever) is to not store it on any computer.
>
> How crazy or userfriendly is that?

I've filed bugs #92271 (ext4) and #92261 (btrfs) in the kernels
bugzilla. That might be a more appropriate place for discussion. Here
are the links:

https://bugzilla.kernel.org/show_bug.cgi?id=92271

https://bugzilla.kernel.org/show_bug.cgi?id=92261

Regards,

Alexander Holler

Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed

[Alexander Holler]

Hello,

besides that calling rm on Linux is just snake oil, the patch below 
still automatically hides the key used to sign modules and offers a 
statistically good chance that the key sometimes might physically 
disappear from the storage used to compile a kernel. So many people 
still might consider it useful. As mentioned below, at least one well 
known person seems to might find it useful too.

Should I rewrite the commit message (e.g. to nothing as the subject 
already describes it perfectly) or is the chance to get such stuff from 
someone outside the holy circles included already zero?

Sorry for asking (that way), but I'm curious if there is really zero 
interest in it.

Regards,

Alexander Holler

Am 23.01.2015 um 02:20 schrieb Alexander Holler:
> I usually throw away (delete) the key used to sign modules after having
> called make -jN (b)zImage modules && make -jN modules_install. Because I've
> got bored to always have to type rm signing_key.* afterwards, I've build
> this patch some time ago.
> As I'm not eager anymore to publish kernel patches, it rested in my private
> chest of patches until I've seen the keynote of Linux.conf.au 2015. It made
> me aware that this patch might have a chance to become included. ;)
>
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
>   Makefile     |  7 +++++++
>   init/Kconfig | 12 ++++++++++++
>   2 files changed, 19 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index fb93350..95e07ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1129,6 +1129,13 @@ _modinst_:
>   	@cp -f $(objtree)/modules.order $(MODLIB)/
>   	@cp -f $(objtree)/modules.builtin $(MODLIB)/
>   	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
> +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
> +	@echo "###"
> +	@echo "### Deleting key used to sign modules."
> +	@echo "###"
> +	@rm ./signing_key.priv
> +	@rm ./signing_key.x509
> +endif
>
>   # This depmod is only for convenience to give the initial
>   # boot a modules.dep even before / is mounted read-write.  However the
> diff --git a/init/Kconfig b/init/Kconfig
> index 9afb971..f29304e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1884,6 +1884,18 @@ config MODULE_SIG_ALL
>   	  Sign all modules during make modules_install. Without this option,
>   	  modules must be signed manually, using the scripts/sign-file tool.
>
> +config MODULE_SIG_THROW_AWAY
> +	bool "Automatically delete the key after modules were installed"
> +	default n
> +	depends on MODULE_SIG_ALL
> +	help
> +	  Delete the key used to sign modules after modules were installed.
> +	  Be aware of the consequences. The downside is that you  won't be
> +	  able to build any module for a (maybe running) kernel, but will
> +	  have to rebuild the kernel and all modules in order to add or modify
> +	  a module. The upside is that you don't have to secure the key in
> +	  order to keep a running kernel safe from unwanted modules.
> +
>   comment "Do not forget to sign required modules with scripts/sign-file"
>   	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
>
>