lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@ahsoftware.de>
>> To: linux-fsdevel@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org, Alexander Holler <holler@ahsoftware.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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>




\
 
 \ /
  Last update: 2015-02-03 16:01    [W:0.101 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site