All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: tytso@mit.edu, mhalcrow@google.com, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org,
	linux-ext4@vger.kernel.org
Subject: A few more filesystem encryption questions
Date: Sun, 3 Apr 2016 00:58:33 -0500	[thread overview]
Message-ID: <20160403055833.GA3214@zzz> (raw)

Hello,

A few more questions about the new filesystem encryption code:

I found that a process without access to the master encryption key can read a
file's full decrypted contents, provided that the file was opened recently by a
process with access to the key.  This is true even if the privileged process
merely opened and closed the file, without reading any bytes.  A similar story
applies to filenames; a 'ls' by a process able to decrypt the names reveals them
to all users/processes.  Essentially, it seems that despite the use of the
kernel keyrings mechanism where different users/processes can have different
keys, this doesn't fully carry over into filesystem encryption.  Is this a known
and understood limitation of the design?

The design document states that an encryption policy can be changed "if the
directory is empty or the file is 0 bytes in length".  However, the code doesn't
allow an existing encryption policy to be changed.  Which behavior was intended?

I had brought up the question of the endianness of the XTS tweak value.  I also
realized that since the page index is used, the XTS tweak will be dependent on
PAGE_SIZE.  So the current behavior is that an encrypted filesystem can only be
read on a device with the same endianness _and_ PAGE_SIZE.  Is is the case that
due to the early Android users, it is too late to start using the byte offset
instead of the PAGE_SIZE?  What about if the XTS tweak was fixed as the number
of 4096-byte blocks from the start of the file as a le64 --- is that what the
existing users are expected to be doing in practice?  Are there any
architectures with PAGE_SIZE < 4096 for which that value wouldn't work?

Eric

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	jaegeuk@kernel.org, tytso@mit.edu, mhalcrow@google.com
Subject: A few more filesystem encryption questions
Date: Sun, 3 Apr 2016 00:58:33 -0500	[thread overview]
Message-ID: <20160403055833.GA3214@zzz> (raw)

Hello,

A few more questions about the new filesystem encryption code:

I found that a process without access to the master encryption key can read a
file's full decrypted contents, provided that the file was opened recently by a
process with access to the key.  This is true even if the privileged process
merely opened and closed the file, without reading any bytes.  A similar story
applies to filenames; a 'ls' by a process able to decrypt the names reveals them
to all users/processes.  Essentially, it seems that despite the use of the
kernel keyrings mechanism where different users/processes can have different
keys, this doesn't fully carry over into filesystem encryption.  Is this a known
and understood limitation of the design?

The design document states that an encryption policy can be changed "if the
directory is empty or the file is 0 bytes in length".  However, the code doesn't
allow an existing encryption policy to be changed.  Which behavior was intended?

I had brought up the question of the endianness of the XTS tweak value.  I also
realized that since the page index is used, the XTS tweak will be dependent on
PAGE_SIZE.  So the current behavior is that an encrypted filesystem can only be
read on a device with the same endianness _and_ PAGE_SIZE.  Is is the case that
due to the early Android users, it is too late to start using the byte offset
instead of the PAGE_SIZE?  What about if the XTS tweak was fixed as the number
of 4096-byte blocks from the start of the file as a le64 --- is that what the
existing users are expected to be doing in practice?  Are there any
architectures with PAGE_SIZE < 4096 for which that value wouldn't work?

Eric

             reply	other threads:[~2016-04-03  5:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-03  5:58 Eric Biggers [this message]
2016-04-03  5:58 ` A few more filesystem encryption questions Eric Biggers
2016-04-03  7:41 ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160403055833.GA3214@zzz \
    --to=ebiggers3@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.