fs/crypto: root read-access without key

fs/crypto: root read-access without key

[Anand Jain]

Hi Ted,

  As of now root[1] can access the plain-text when the data is cached
  by the user-with-the-key and, root gets error no-key when data is
  not cached by the user-with-the-key. I think this behavior is a
  bug if not, wrong design, or looks like I am missing something.

  [1] for that matter any user who has read access to the files but
  does not have the keys.

Repo:
-----------
The user enters key of edir-user
$ e4crypt add_key /ext4/edir-user/

root with no-key is not able to read file-data yet.

# cat /ext4/edir-user/tf1
cat: tf1: Required key not available

now the user above, reads tf1
$ cat /ext4/edir-user/tf1
this is test created by user

So now root with no-key is able to read the file
# cat /ext4/edir-user/tf1
this is test created by user
-----------

  Instead, this should either always return cipher-text (thru DIO)
  or always return error-no-key. So that, behavior does not depend
  file-data cache.

  Hope we agree on the common behavior, BTRFS as of now returns
  error-no-key for all users without-the-key, however in the long
  term when relevant code is ready, it would be beneficial to
  provide the cipher-text in this context and the encryption
  metadata through the xattr. So that, we could use rsync -X
  without-key, to back up the encrypted files which will also copy
  the required encryption metadata through the extended attributes.
  Next, when rsync -X is run when key-is-in, it would read
  plain-text but no encryption metadata should be read at this time,
  as it has already reading the plain-text anyway. In this way
  we control the backup and restore.

  This may be controversial but just the idea floating so that we
  have better compatibility and, as probably extended attribute
  is more common across other OSs including NTFS, hopefully one day
  we could backup encrypted-file across FSs without having to decrypt,
  and decrypt at the destination only when required. This also
  means we need page->index to be common or we can provide such
  info through the extended attributes again or fs/crypto v2
  could add a feature to drop encryption metadata dependency on
  the page->index.

Thanks, Anand

Re: fs/crypto: root read-access without key

[Richard Weinberger]

Anand,

On Tue, Feb 14, 2017 at 11:18 AM, Anand Jain <anand.jain@oracle.com> wrote:
>
> Hi Ted,
>
>  As of now root[1] can access the plain-text when the data is cached
>  by the user-with-the-key and, root gets error no-key when data is
>  not cached by the user-with-the-key. I think this behavior is a
>  bug if not, wrong design, or looks like I am missing something.
>
>  [1] for that matter any user who has read access to the files but
>  does not have the keys.

Well, as soon the key is loaded plaintext of pages and filenames will be
stored in page- and dcache and any users that can access the files will
see the plaintext.

If you want to keep /secret really secret you have to apply correct DAC/MAC
permissions as well.
Or put /secret into a private mount namespace.

-- 
Thanks,
//richard

Re: fs/crypto: root read-access without key

[Anand Jain]

Hi Richard,


>>  As of now root[1] can access the plain-text when the data is cached
>>  by the user-with-the-key and, root gets error no-key when data is
>>  not cached by the user-with-the-key. I think this behavior is a
>>  bug if not, wrong design, or looks like I am missing something.
>>
>>  [1] for that matter any user who has read access to the files but
>>  does not have the keys.
>
> Well, as soon the key is loaded plaintext of pages and filenames will be
> stored in page- and dcache and any users that can access the files will
> see the plaintext.
>
> If you want to keep /secret really secret you have to apply correct DAC/MAC
> permissions as well.
> Or put /secret into a private mount namespace.

Right. Keeping the secret really secret wasn't the point I was trying to 
make instead, irrespective of whether the plain-text is cached or 
not-cached by the key-user, the behavior for the no-key-user access has 
to be constant. More about it is in the email above.

Thanks,
-Anand

Re: fs/crypto: root read-access without key

[Richard Weinberger]

Anand,

Am 14.02.2017 um 13:50 schrieb Anand Jain:
> 
> Hi Richard,
> 
> 
>>>  As of now root[1] can access the plain-text when the data is cached
>>>  by the user-with-the-key and, root gets error no-key when data is
>>>  not cached by the user-with-the-key. I think this behavior is a
>>>  bug if not, wrong design, or looks like I am missing something.
>>>
>>>  [1] for that matter any user who has read access to the files but
>>>  does not have the keys.
>>
>> Well, as soon the key is loaded plaintext of pages and filenames will be
>> stored in page- and dcache and any users that can access the files will
>> see the plaintext.
>>
>> If you want to keep /secret really secret you have to apply correct DAC/MAC
>> permissions as well.
>> Or put /secret into a private mount namespace.
> 
> Right. Keeping the secret really secret wasn't the point I was trying to make instead, irrespective of whether the plain-text is cached or not-cached by the key-user, the behavior
> for the no-key-user access has to be constant. More about it is in the email above.

Hmmm, your fear is that a backup tool will sometimes store the unencrypted file and sometimes not?
I'd argue that such a tool should either have the key or no search access to /secret.

Thanks,
//richard

Re: fs/crypto: root read-access without key

[Theodore Ts'o]

On Tue, Feb 14, 2017 at 06:18:20PM +0800, Anand Jain wrote:
> 
> Hi Ted,
> 
>  As of now root[1] can access the plain-text when the data is cached
>  by the user-with-the-key and, root gets error no-key when data is
>  not cached by the user-with-the-key. I think this behavior is a
>  bug if not, wrong design, or looks like I am missing something.
> 
>  [1] for that matter any user who has read access to the files but
>  does not have the keys.

This is an explicit design decision.  The main issue is that the VFS
and the page cache fundamntally assumes that there is only a single
"view" of the state of the files.  So once something is cached in the
dcache and the page cache, the VFS will happily return it to any user
who has permissions.  The file system doesn't even get involved.

We could try and fix this by adding our own file system unique
premissions check, but that slows down every single file open with a
keyring search.  It also isn't a complete solution because if you pass
the fd around via a unix domain socket, or some such you can still end
up with weirdness where whether or not the process which is currently
trying to operate on the fd has access to the key (via the rings
unique, wild, and wonderful, and nonstandard/non-POSIX keyring access
scheme).

It also isn't complete, since someone could infer whether or not a
file exists, unless we also completely spike out the dcache, which
would be an even worse performance disaster.

So the current model is that if you want to protect file, the Unix
permissions do have to be set correctly, and root can read everything.
The presense or absense of keys is *not* currently intended to be an
access control mechanism.

						- Ted

Re: fs/crypto: root read-access without key

[Al Viro]

On Tue, Feb 14, 2017 at 10:50:23AM -0500, Theodore Ts'o wrote:

> It also isn't complete, since someone could infer whether or not a
> file exists, unless we also completely spike out the dcache, which
> would be an even worse performance disaster.
> 
> So the current model is that if you want to protect file, the Unix
> permissions do have to be set correctly, and root can read everything.
> The presense or absense of keys is *not* currently intended to be an
> access control mechanism.

Not that root couldn't simply take over any process of the user in
question and ptrace its way into issuing arbitrary syscalls...

Re: fs/crypto: root read-access without key

[Anand Jain]

>>  As of now root[1] can access the plain-text when the data is cached
>>  by the user-with-the-key and, root gets error no-key when data is
>>  not cached by the user-with-the-key. I think this behavior is a
>>  bug if not, wrong design, or looks like I am missing something.
>>
>>  [1] for that matter any user who has read access to the files but
>>  does not have the keys.

> This is an explicit design decision.  The main issue is that the VFS
> and the page cache fundamntally assumes that there is only a single
> "view" of the state of the files.  So once something is cached in the
> dcache and the page cache, the VFS will happily return it to any user
> who has permissions.  The file system doesn't even get involved.

  dcache: yeah its complicated, however I still don't know why
  file-name was the data-to-protected in the first place. Next,

  page: a read request by the no-key-user can be checked [1] and
  returned either ENOKEY or cipher-text using dio.

  [1] struct inode has crypto_info so it can check the key status
  and, further more its not at the permission check so no performance
  impact.

> We could try and fix this by adding our own file system unique
> premissions check, but that slows down every single file open with a
> keyring search.

  not unless file-name encryption is part of the data to be
  encrypted as above.

>  It also isn't a complete solution because if you pass
> the fd around via a unix domain socket, or some such you can still end
> up with weirdness where whether or not the process which is currently
> trying to operate on the fd has access to the key (via the rings
> unique, wild, and wonderful, and nonstandard/non-POSIX keyring access
> scheme).

  Again this is only applicable in the context of file-name
  encryption.

> It also isn't complete, since someone could infer whether or not a
> file exists, unless we also completely spike out the dcache, which
> would be an even worse performance disaster.

  part of the file-name encryption only problem.

> So the current model is that if you want to protect file, the Unix
> permissions do have to be set correctly, and root can read everything.
> The presense or absense of keys is *not* currently intended to be an
> access control mechanism.

  yeah encryption is not about the access control itself, I echo
  that myself often.

  Factually the problem here is with the file-name encryption (FNE),
  And, I still don't know the relation between FNE and the Evil Maid
  attack which, I have been told as the reason for the mandatory
  FNE for all solutions.

  Last but not least, the whole purpose of having the encryption
  metadata to be at the attribute is to facilitate the compatibility
  with the existing tools rsync -X ; cp --preserve. IMO we have
  entirely defeated that purpose here.

Thanks, Anand

Re: fs/crypto: root read-access without key

[Theodore Ts'o]

On Tue, Feb 14, 2017 at 07:00:40PM +0000, Al Viro wrote:
> On Tue, Feb 14, 2017 at 10:50:23AM -0500, Theodore Ts'o wrote:
> 
> > It also isn't complete, since someone could infer whether or not a
> > file exists, unless we also completely spike out the dcache, which
> > would be an even worse performance disaster.
> > 
> > So the current model is that if you want to protect file, the Unix
> > permissions do have to be set correctly, and root can read everything.
> > The presense or absense of keys is *not* currently intended to be an
> > access control mechanism.
> 
> Not that root couldn't simply take over any process of the user in
> question and ptrace its way into issuing arbitrary syscalls...

Well, that might not be true if someone makes the file group readable
and the group includes some user which doesn't have the key.  I
consider that a configuration bug, but yes, as far as restricted root,
that's really only for those people who are comforted by the
_illusion_ of security.  Sort of like TSA patdowns at airports.  :-)

	      		      	      	  - Ted

Re: fs/crypto: root read-access without key

[Eric Biggers]

Hi Anand,

On Wed, Feb 15, 2017 at 04:04:37PM +0800, Anand Jain wrote:
> 
>  dcache: yeah its complicated, however I still don't know why
>  file-name was the data-to-protected in the first place. Next,
> 
>  page: a read request by the no-key-user can be checked [1] and
>  returned either ENOKEY or cipher-text using dio.
> 
>  [1] struct inode has crypto_info so it can check the key status
>  and, further more its not at the permission check so no performance
>  impact.
> 

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.

> > We could try and fix this by adding our own file system unique
> > premissions check, but that slows down every single file open with a
> > keyring search.
> 
>  not unless file-name encryption is part of the data to be
>  encrypted as above.

No, if a permission check were to be added, then it would need to be done for
both regular files (contents encryption) and for directories and symlinks
(filenames encryption).

> 
> >  It also isn't a complete solution because if you pass
> > the fd around via a unix domain socket, or some such you can still end
> > up with weirdness where whether or not the process which is currently
> > trying to operate on the fd has access to the key (via the rings
> > unique, wild, and wonderful, and nonstandard/non-POSIX keyring access
> > scheme).
> 
>  Again this is only applicable in the context of file-name
>  encryption.

No, it's applicable for both contents and filenames encryption, because the file
descriptor could refer to either a regular file (contents encryption) or
directory (filenames encryption).

> 
> > It also isn't complete, since someone could infer whether or not a
> > file exists, unless we also completely spike out the dcache, which
> > would be an even worse performance disaster.
> 
>  part of the file-name encryption only problem.

Well, you could say that, but of course without filename encryption then anyone
can see which filenames exist without having to resort to any clever attacks...

> 
> > So the current model is that if you want to protect file, the Unix
> > permissions do have to be set correctly, and root can read everything.
> > The presense or absense of keys is *not* currently intended to be an
> > access control mechanism.
> 
>  yeah encryption is not about the access control itself, I echo
>  that myself often.
> 
>  Factually the problem here is with the file-name encryption (FNE),
>  And, I still don't know the relation between FNE and the Evil Maid
>  attack which, I have been told as the reason for the mandatory
>  FNE for all solutions.

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.  Second, the filesystem
enforces that every file in a given directory tree uses the same encryption
policy, which makes it more difficult for encryption to be maliciously weakened
or removed (or even impossible, if a trusted process verifies the top-level
encryption policies).

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.

> 
>  Last but not least, the whole purpose of having the encryption
>  metadata to be at the attribute is to facilitate the compatibility
>  with the existing tools rsync -X ; cp --preserve. IMO we have
>  entirely defeated that purpose here.
> 

Well, the reason it is being stored in an extended attribute (at least for ext4,
f2fs, and ubifs; other filesystems could do it differently) is that this was the
only logical place to put it, and easy to implement.  If somehow only 4-8 bytes
of metadata were needed then it could have been added to the inodes directly,
but it is 28 bytes and will probably get larger in the future.

As for the mostly separate question of the API, this was already covered to a
large extent, but the semantics of the encryption metadata are not like a normal
xattr.  If it *was* exposed it through the xattr system calls, without special
semantics, then there would be some very strange things users could do and
resulting problems that would need to be solved, for example:

* create a file, write some data to it, then set an encryption xattr.  This
  would suddenly change the interpretation of the data; now what was previously
  the plaintext is now the ciphertext.  What happens if pages of the file have
  already been cached or even mmap'ed?

* remove the encryption xattr.  Similar problem; the interpretation of the data
  suddenly changes: now what was previously the ciphertext is now the plaintext.
  What happens if pages are already cached or mmap'ed?

* apply an encryption xattr to a directory after it already has files in it.
  Are the names of those files supposed to be unencrypted or are they supposed
  to be encrypted?

* allow userspace to choose the per-file nonce.  How do you ensure that
  userspace doesn't repeat nonces?  Note that this would happen trivially if a
  file is copied.

So I don't think it is realistic to support backup/restore of "locked" encrypted
files without a special API.  (And I think other OS's tend to do things the same
way, e.g. on Windows note the special functions for backup/restore of EFS
files.)  Of course, if you have a proposed solution for how this would in fact
be possible, then I'm sure people would be willing to listen.

Eric

Re: fs/crypto: root read-access without key

[Anand Jain]

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