From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp1040.oracle.com ([156.151.31.81]:18147 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934122AbdBQRJ0 (ORCPT ); Fri, 17 Feb 2017 12:09:26 -0500 From: Anand Jain Subject: Re: fs/crypto: root read-access without key To: Eric Biggers References: <8f00a43e-c6eb-265e-f3ca-d306179d61d9@oracle.com> <20170214155023.y3xideahis6xtlgv@thunk.org> <20170217044315.GB634@zzz> Cc: "Theodore Ts'o" , linux-fsdevel Message-ID: <367bee98-c33f-85b4-9903-b46d0c8c0213@oracle.com> Date: Sat, 18 Feb 2017 01:13:58 +0800 MIME-Version: 1.0 In-Reply-To: <20170217044315.GB634@zzz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Eric, > This is incorrect because for a file there is one only inode system-wide, not > one inode per user (or per process). So everyone will either see the key in the > inode or not. Well I didn't say inode per user. As I said inode has Key pointer, and if its not for the file-name then there is no requisite to check key during directory lookup, which apparently seems to be reason for the performance hit. > There are actually several separate protections against such attacks. First, > the encryption of both contents and filenames makes it more difficult (though > not necessarily impossible) to identify target files. Well its not done in the right way. as below. > Not encrypting filenames would not be the end of the world, but it's a security > enhancement which is nice to have. And I think you are blaming filenames > encryption specifically for things which are actually more general concerns. An identifiable dir/file name isn't the problem. The problem is that the policy on the directory is modifiable/removable by the attacker. Encrypting the file name for this purpose is just not convincing to me. Thanks, Anand