linux-kernel - A few more filesystem encryption questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160403055833.GA3214@zzz>
Date:	Sun, 3 Apr 2016 00:58:33 -0500
From:	Eric Biggers <ebiggers3@...il.com>
To:	linux-fsdevel@...r.kernel.org
Cc:	linux-f2fs-devel@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org, jaegeuk@...nel.org, tytso@....edu,
	mhalcrow@...gle.com
Subject: A few more filesystem encryption questions

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