* [PATCH] modsign: provide option to automatically delete the key after modules were installed @ 2015-01-23 1:20 Alexander Holler 2015-01-23 9:24 ` Michal Marek ` (3 more replies) 0 siblings, 4 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-23 1:20 UTC (permalink / raw) To: linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds, 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 ^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 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 21:57 ` [PATCH] modsign: overwrite keys with zero before deleting them Alexander Holler ` (2 subsequent siblings) 3 siblings, 1 reply; 36+ messages in thread From: Michal Marek @ 2015-01-23 9:24 UTC (permalink / raw) To: Alexander Holler, linux-kernel Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 9:24 ` Michal Marek @ 2015-01-23 9:39 ` Alexander Holler 2015-01-23 10:15 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 9:39 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 9:39 ` Alexander Holler @ 2015-01-23 10:15 ` Alexander Holler 2015-01-23 10:55 ` Michal Marek 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 10:15 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 10:15 ` Alexander Holler @ 2015-01-23 10:55 ` Michal Marek 2015-01-23 11:43 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Michal Marek @ 2015-01-23 10:55 UTC (permalink / raw) To: Alexander Holler, linux-kernel Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 10:55 ` Michal Marek @ 2015-01-23 11:43 ` Alexander Holler 2015-01-23 11:54 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 11:43 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 11:43 ` Alexander Holler @ 2015-01-23 11:54 ` Alexander Holler 2015-01-23 12:34 ` Alexander Holler 2015-01-23 12:56 ` David Howells 0 siblings, 2 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-23 11:54 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 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 1 sibling, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 12:34 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 12:34 ` Alexander Holler @ 2015-01-23 18:26 ` Alexander Holler 0 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-23 18:26 UTC (permalink / raw) To: Michal Marek, linux-kernel; +Cc: linux-kbuild, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 11:54 ` Alexander Holler 2015-01-23 12:34 ` Alexander Holler @ 2015-01-23 12:56 ` David Howells 2015-01-23 13:27 ` Alexander Holler 1 sibling, 1 reply; 36+ messages in thread From: David Howells @ 2015-01-23 12:56 UTC (permalink / raw) To: Alexander Holler Cc: dhowells, Michal Marek, linux-kernel, linux-kbuild, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 12:56 ` David Howells @ 2015-01-23 13:27 ` Alexander Holler 2015-01-23 13:35 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 13:27 UTC (permalink / raw) To: David Howells; +Cc: Michal Marek, linux-kernel, linux-kbuild, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 13:27 ` Alexander Holler @ 2015-01-23 13:35 ` Alexander Holler 0 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-23 13:35 UTC (permalink / raw) To: David Howells; +Cc: Michal Marek, linux-kernel, linux-kbuild, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH] modsign: overwrite keys with zero before deleting them 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 21:57 ` Alexander Holler 2015-01-23 22:06 ` Richard Weinberger 2015-01-23 23:58 ` David Howells 2015-07-18 21:56 ` [PATCH] modsign: provide option to automatically delete the key after modules were installed Alexander Holler 3 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-23 21:57 UTC (permalink / raw) To: linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds, 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 ^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: overwrite keys with zero before deleting them 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 0 siblings, 1 reply; 36+ messages in thread From: Richard Weinberger @ 2015-01-23 22:06 UTC (permalink / raw) To: Alexander Holler Cc: LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: overwrite keys with zero before deleting them 2015-01-23 22:06 ` Richard Weinberger @ 2015-01-23 22:16 ` Alexander Holler 0 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-23 22:16 UTC (permalink / raw) To: Richard Weinberger Cc: LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: overwrite keys with zero before deleting them 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 21:57 ` [PATCH] modsign: overwrite keys with zero before deleting them Alexander Holler @ 2015-01-23 23:58 ` David Howells 2015-01-24 0:13 ` Alexander Holler 2015-07-18 21:56 ` [PATCH] modsign: provide option to automatically delete the key after modules were installed Alexander Holler 3 siblings, 1 reply; 36+ messages in thread From: David Howells @ 2015-01-23 23:58 UTC (permalink / raw) To: Alexander Holler Cc: dhowells, linux-kernel, linux-kbuild, Michal Marek, Linus Torvalds Alexander Holler <holler@ahsoftware.de> wrote: > This is for the more paranoid people, also it's > questionable what paranoid nowadays means. shred? David ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: overwrite keys with zero before deleting them 2015-01-23 23:58 ` David Howells @ 2015-01-24 0:13 ` Alexander Holler 2015-01-24 1:27 ` Pádraig Brady 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-24 0:13 UTC (permalink / raw) To: David Howells; +Cc: linux-kernel, linux-kbuild, Michal Marek, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: overwrite keys with zero before deleting them 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 0 siblings, 1 reply; 36+ messages in thread From: Pádraig Brady @ 2015-01-24 1:27 UTC (permalink / raw) To: Alexander Holler, David Howells Cc: linux-kernel, linux-kbuild, Michal Marek, Linus Torvalds 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-24 1:27 ` Pádraig Brady @ 2015-01-24 10:45 ` Alexander Holler 2015-01-24 11:37 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-24 10:45 UTC (permalink / raw) To: linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds, 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 ^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 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 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-24 11:37 UTC (permalink / raw) To: linux-kernel; +Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-24 11:37 ` Alexander Holler @ 2015-01-24 12:09 ` Alexander Holler 2015-01-24 12:29 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-24 12:09 UTC (permalink / raw) To: linux-kernel; +Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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(). ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-24 12:09 ` Alexander Holler @ 2015-01-24 12:29 ` Alexander Holler 2015-01-25 2:13 ` Pádraig Brady 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-24 12:29 UTC (permalink / raw) To: linux-kernel; +Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-24 12:29 ` Alexander Holler @ 2015-01-25 2:13 ` Pádraig Brady 2015-01-25 2:43 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Pádraig Brady @ 2015-01-25 2:13 UTC (permalink / raw) To: Alexander Holler, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 2:13 ` Pádraig Brady @ 2015-01-25 2:43 ` Alexander Holler 2015-01-25 10:32 ` Alexander Holler 0 siblings, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-25 2:43 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 2:43 ` Alexander Holler @ 2015-01-25 10:32 ` Alexander Holler 2015-01-25 10:57 ` Alexander Holler 2015-01-29 22:39 ` Alexander Holler 0 siblings, 2 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 10:32 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 10:32 ` Alexander Holler @ 2015-01-25 10:57 ` Alexander Holler 2015-01-25 11:42 ` Alexander Holler 2015-01-29 22:39 ` Alexander Holler 1 sibling, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-25 10:57 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 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 0 siblings, 2 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 11:42 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 11:42 ` Alexander Holler @ 2015-01-25 12:04 ` Alexander Holler 2015-01-25 12:08 ` Richard Weinberger 1 sibling, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 12:04 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 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 1 sibling, 1 reply; 36+ messages in thread From: Richard Weinberger @ 2015-01-25 12:08 UTC (permalink / raw) To: Alexander Holler Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 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:36 ` Alexander Holler 0 siblings, 2 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 12:24 UTC (permalink / raw) To: Richard Weinberger Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 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 1 sibling, 1 reply; 36+ messages in thread From: Richard Weinberger @ 2015-01-25 12:28 UTC (permalink / raw) To: Alexander Holler Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 12:28 ` Richard Weinberger @ 2015-01-25 12:57 ` Alexander Holler 0 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 12:57 UTC (permalink / raw) To: Richard Weinberger Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 12:24 ` Alexander Holler 2015-01-25 12:28 ` Richard Weinberger @ 2015-01-25 12:36 ` Alexander Holler 2015-01-25 13:46 ` Alexander Holler 1 sibling, 1 reply; 36+ messages in thread From: Alexander Holler @ 2015-01-25 12:36 UTC (permalink / raw) To: Richard Weinberger Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 12:36 ` Alexander Holler @ 2015-01-25 13:46 ` Alexander Holler 0 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-25 13:46 UTC (permalink / raw) To: Richard Weinberger Cc: Pádraig Brady, LKML, linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it 2015-01-25 10:32 ` Alexander Holler 2015-01-25 10:57 ` Alexander Holler @ 2015-01-29 22:39 ` Alexander Holler 1 sibling, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-01-29 22:39 UTC (permalink / raw) To: Pádraig Brady, linux-kernel Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] modsign: provide option to automatically delete the key after modules were installed 2015-01-23 1:20 [PATCH] modsign: provide option to automatically delete the key after modules were installed Alexander Holler ` (2 preceding siblings ...) 2015-01-23 23:58 ` David Howells @ 2015-07-18 21:56 ` Alexander Holler 3 siblings, 0 replies; 36+ messages in thread From: Alexander Holler @ 2015-07-18 21:56 UTC (permalink / raw) To: linux-kernel; +Cc: linux-kbuild, Michal Marek, David Howells, Linus Torvalds 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 > > ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2015-07-18 21:57 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.