From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Subject: Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files Date: Tue, 03 Feb 2015 15:50:53 +0100 Message-ID: <54D0E04D.60403@ahsoftware.de> References: <1422896713-25367-1-git-send-email-holler@ahsoftware.de> <1422896713-25367-4-git-send-email-holler@ahsoftware.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: =?windows-1252?Q?Luk=E1=9A_Czerner?= Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Am 03.02.2015 um 14:50 schrieb Luk=E1=9A Czerner: > On Mon, 2 Feb 2015, Alexander Holler wrote: > >> Date: Mon, 2 Feb 2015 18:05:11 +0100 >> From: Alexander Holler >> To: linux-fsdevel@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org, Alexander Holler >> Subject: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure = deletion >> of files > > Hi, > > I am missing a description, where you'd describe what is this all > about, why and how. Maybe you've missed the introduction, patch 0/5. Sorry, but I'm not sponsored and the time I can spend is limited.=20 Therefor, please, don't expect a paper in the kind european=20 bureaucrazies are producing. I'm already spending a lot of time trying to convince the developers=20 here, that this a feature most people expect from any filesystem. And=20 I've written these patches, for which now, even after I've marked them=20 with all kind of "preliminary" terms, still get blamed. And, unfortunately, myths like that overwriting a block once on=20 traditional magnetic platters isn't enough, don't help either. > I am missing very important pieces like, what happens if we require > secure delete, but there is no secure trim available and we're still > on the ssd ? As written in 0/5, I don't know if trim (without secure) might be enoug= h. > > What if the underlying storage is thinly provisioned ? > > What if the underlying storage consist of hardware which does > support secure discard and one that does not ? The request crossing > the borders will fail. > > What if the underlying hardware does support secure trim, but the > storage under the fs is in raid configuration, which brings me to > the next question. That's all about how unlinkat_s will be documented. I would suggest to=20 let unlinkat_s() fail if it is sure it can't delete stuff, but otherwis= e=20 would write in the documentation that it might be useless in many cases= =20 like stacked filesystems, mixed raids and similiar constructs. Maybe th= e=20 documentation for shred is something which could be used as an template= =2E > > Discard/secure discard does have a granularity and alignment, so > what if the extent is smaller than a discard granularity, or it is > not aligned properly ? Such discard requests would be ignored. You can throw in another dozen complications. That's just another way t= o=20 say "never", to kill any further user expectations or requests and to=20 hide the forest behind trees. I wonder how you ever solve problems if you never start with solving=20 even the most trivial case, always getting lost in an uncountbale numbe= r=20 of problems. > Error handling is missing here. Also I am not sure that zeroing out > the blocks is really enough. Yes, I've seen the link you've posted, > but I am not convinced. Implementing a sb_issue_zeroout_30_times() should be trivial. You could= =20 even make that an mount option, if that would convince you. But besides= =20 that, I've never heared of any case where someone has read anything bac= k=20 which was overwritten just once. But in contrast, there are countless=20 case where stuff was read back because the filesystem didn't really=20 delete it. > > Did you consider metadata information for the file ? File name, > timestamps, size, data placement ? Is it something you want to > remove as well, or are you going to ignore it ? It can potentially > contain valuable information for the attacker as well. I am just > trying to understand the scope of this thing. I prefer to start with simple steps to cover a least the most trivial=20 cases which already would make 99% percent of users happy. You can=20 always find some cases when it doesn't work and you could always make=20 unlinkat_s() more complicated. I'm aware of all the other stuff you are mentioning below, but I'll now= =20 stop arguing further. Sorry, I've already expected all these response,=20 but at least, I've tried it in the hope someone else might still see th= e=20 forest behind all those trees. Maybe I should request removal of shred from Fedora/RH instead.=20 According to you it's one of the most misleading and useless tools. So=20 why still confuse people with it and still ship it? Have a nice day, week or year ... Regards, Alexander Holler > > Moreover with inline data you might have the data in the inode > itself, which also means the it will be in the journal as well. > > Also with data=3Djournal the data will be in the journal. > > With no journal this would not work at all, you have to make this > for nojournal case as well. > > What if you do defragmentation in the file, in that case the file dat= a > could be all over the place. > > What if you're device is not a real hardware, but just let's say a > loop device ? Talking about the smart phones I had Samsung phone > with that setup (not sure anyone is doing that anymore). > > > With all that said, the devil is in the details and since it's > security feature the details and corner cases is what you need > to focus on. We have '-o discard' mount option for years now and > we could have made 'secure delete' by simply calling > sb_issue_discard() with BLKDEV_DISCARD_SECURE flag, but that's not > really enough. > > Not mentioning the unreliable hardware. And I am not going to rely > on the hardware which was not designed with security in mind for my > security feature, no one should. It's much better, easies and more > feasible just to use disk encryption - it also comes with advantages > that no one can actually read your existing files as opposed to just > deleted files. > >> err =3D ext4_mb_load_buddy(sb, entry->efd_group, &e4b); >> /* we expect to find existing buddy because it's pinned */ >> BUG_ON(err !=3D 0); >> diff --git a/fs/ext4/super.c b/fs/ext4/super.c >> index 2c9e686..f87e3ff 100644 >> --- a/fs/ext4/super.c >> +++ b/fs/ext4/super.c >> @@ -1100,6 +1100,17 @@ static const struct quotactl_ops ext4_qctl_sy= sfile_operations =3D { >> }; >> #endif >> >> +static void ext4_set_secure_delete(struct super_block *sb, bool sec= ure) >> +{ >> + struct ext4_sb_info *sbi =3D EXT4_SB(sb); >> + // TODO: will overflow with a very large number of >> + // concurrent calls of unlinkat_s(). >> + if (secure) >> + atomic_inc(&sbi->secure_delete); >> + else >> + atomic_dec(&sbi->secure_delete); >> +} >> + >> static const struct super_operations ext4_sops =3D { >> .alloc_inode =3D ext4_alloc_inode, >> .destroy_inode =3D ext4_destroy_inode, >> @@ -1119,6 +1130,7 @@ static const struct super_operations ext4_sops= =3D { >> .quota_write =3D ext4_quota_write, >> #endif >> .bdev_try_to_free_page =3D bdev_try_to_free_page, >> + .set_secure_delete =3D ext4_set_secure_delete, >> }; >> >> static const struct export_operations ext4_export_ops =3D { >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kerne= l" 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/ >