| Message ID | 1422096327-4483-1-git-send-email-holler@ahsoftware.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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(). -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(-)