Date:	Tue, 03 Feb 2015 15:50:53 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Lukáš Czerner <lczerner@...hat.com>
CC:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion
 of files

Am 03.02.2015 um 14:50 schrieb Lukáš Czerner:
> On Mon, 2 Feb 2015, Alexander Holler wrote:
>
>> Date: Mon,  2 Feb 2015 18:05:11 +0100
>> From: Alexander Holler <holler@...oftware.de>
>> To: linux-fsdevel@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org, Alexander Holler <holler@...oftware.de>
>> 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. 
Therefor, please, don't expect a paper in the kind european 
bureaucrazies are producing.

I'm already spending a lot of time trying to convince the developers 
here, that this a feature most people expect from any filesystem. And 
I've written these patches, for which now, even after I've marked them 
with all kind of "preliminary" terms, still get blamed.

And, unfortunately, myths like that overwriting a block once on 
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 enough.

>
> 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 
let unlinkat_s() fail if it is sure it can't delete stuff, but otherwise 
would write in the documentation that it might be useless in many cases 
like stacked filesystems, mixed raids and similiar constructs. Maybe the 
documentation for shred is something which could be used as an template.

>
> 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 to 
say "never", to kill any further user expectations or requests and to 
hide the forest behind trees.

I wonder how you ever solve problems if you never start with solving 
even the most trivial case, always getting lost in an uncountbale number 
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 
even make that an mount option, if that would convince you. But besides 
that, I've never heared of any case where someone has read anything back 
which was overwritten just once. But in contrast, there are countless 
case where stuff was read back because the filesystem didn't really 
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 
cases which already would make 99% percent of users happy. You can 
always find some cases when it doesn't work and you could always make 
unlinkat_s() more complicated.

I'm aware of all the other stuff you are mentioning below, but I'll now 
stop arguing further. Sorry, I've already expected all these response, 
but at least, I've tried it in the hope someone else might still see the 
forest behind all those trees.

Maybe I should request removal of shred from Fedora/RH instead. 
According to you it's one of the most misleading and useless tools. So 
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=journal 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 data
> 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 = ext4_mb_load_buddy(sb, entry->efd_group, &e4b);
>>   	/* we expect to find existing buddy because it's pinned */
>>   	BUG_ON(err != 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_sysfile_operations = {
>>   };
>>   #endif
>>
>> +static void ext4_set_secure_delete(struct super_block *sb, bool secure)
>> +{
>> +	struct ext4_sb_info *sbi = 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 = {
>>   	.alloc_inode	= ext4_alloc_inode,
>>   	.destroy_inode	= ext4_destroy_inode,
>> @@ -1119,6 +1130,7 @@ static const struct super_operations ext4_sops = {
>>   	.quota_write	= ext4_quota_write,
>>   #endif
>>   	.bdev_try_to_free_page = bdev_try_to_free_page,
>> +	.set_secure_delete = ext4_set_secure_delete,
>>   };
>>
>>   static const struct export_operations ext4_export_ops = {
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists