On Mon, Oct 23, 2017 at 02:40:34PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There are going to be more filesystem encryption definitions added, and
> we don't want to use a disproportionate amount of space in
> for filesystem encryption stuff. So move the fscrypt definitions to a
> n
On Mon, Oct 23, 2017 at 02:40:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Prefix all filesystem encryption UAPI constants except the ioctl numbers
> with "FSCRYPT_" rather than with "FS_". This namespaces the constants
> more appropriately and makes it clear that they are related sp
On Mon, Oct 23, 2017 at 02:40:36PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Update the filesystem encryption kernel code to use the new names for
> the UAPI constants rather than the old names.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Michael Halcrow
> ---
> fs/crypto/fname.c
On Mon, Oct 23, 2017 at 02:40:37PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In preparation for introducing a new way to find the master keys and
> derive the per-file keys, clean up the current method. This includes:
>
> - Introduce a helper function find_and_derive_key() so that we
On Mon, Oct 23, 2017 at 02:40:38PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Add an ->s_master_keys keyring to 'struct super_block' for holding
> encryption keys which have been added to the filesystem. This keyring
> will be populated using a new fscrypt ioctl.
>
> This is needed for
On Mon, Oct 23, 2017 at 02:40:39PM -0700, Eric Biggers wrote:
> By having an API to add a key to the *filesystem* we'll be able to
> eliminate all the above hacks and better express the intended semantics:
> the "locked/unlocked" status of an encrypted directory is global. And
> orthogonally to en
On Mon, Oct 23, 2017 at 02:40:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When a filesystem encryption key is removed, we need all files which had
> been "unlocked" (had ->i_crypt_info set up) with it to appear "locked"
> again. This is most easily done by evicting the inodes. This
Given recent talk I've seen on potentially applying file-based
protections in NFS, I think it's worth making some cautionary
observations at this stage.
Moxie's Cryptographic Doom Principle is an approachable take on the
argument that one should verify before performing any other
cryptographic ope
On Wed, Jul 12, 2017 at 02:00:30PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Currently, the fscrypt_context (i.e. the encryption xattr) does not
> contain a cryptographically secure identifier for the master key's
> payload. Therefore it's not possible to verify that the correct key wa
On Wed, Jul 12, 2017 at 02:00:31PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In struct fscrypt_info, ->ci_master_key is the master key descriptor,
> not the master key itself. In preparation for introducing a struct
> fscrypt_master_key and making ->ci_master_key point to it, rename th
On Wed, Jul 12, 2017 at 02:00:32PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> By design, the keys which userspace provides in the keyring are not used
> to encrypt data directly. Instead, a KDF (Key Derivation Function) is
> used to derive a unique encryption key for each inode, given a
On Wed, Jul 12, 2017 at 02:00:33PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Currently, while a fscrypt master key is required to have a certain
> description in the keyring, its payload is never verified to be correct.
> While sufficient for well-behaved userspace, this is insecure in
On Fri, Jul 14, 2017 at 09:24:40AM -0700, Michael Halcrow wrote:
> On Wed, Jul 12, 2017 at 02:00:32PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > By design, the keys which userspace provides in the keyring are not used
> > to encrypt data directly. Instead, a KDF (Key Derivation Fu
On Wed, Jul 12, 2017 at 02:00:34PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Now that we have a key_hash field which securely identifies a master key
> payload, introduce a cache of the HMAC transforms for the master keys
> currently in use for inodes using v2+ encryption policies. The
On Wed, Jul 12, 2017 at 02:00:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Since v2 encryption policies are opt-in, take the opportunity to also
> drop support for the legacy filesystem-specific key description prefixes
> "ext4:", "f2fs:", and "ubifs:", instead requiring the generic p
On Thu, Aug 31, 2017 at 05:02:17PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Perhaps long overdue, add a documentation file for filesystem-level
> encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
> directory. The new file is based loosely on the latest version of the
> "E
Gives user space the opportunity to fall back to copy-and-delete.
Signed-off-by: Michael Halcrow
---
fs/ext4/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index c1cf020d1889..3c493bc4273d 100644
--- a/fs/ext4/namei.c
+++ b/fs/
Gives user space the opportunity to fall back to copy-and-delete.
Signed-off-by: Michael Halcrow
---
fs/f2fs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 760d85223c81..689c671cf8b8 100644
--- a/fs/f2fs/namei.c
+++ b/fs/
Currently file systems support fscrypto will return -EPERM when the
user attempts to link, rename, or cross-rename between two directories
that have incompatible encryption policy contexts. User space tools
will fail the operation when receiving this errno. With -EXDEV, user
space tools will typi
Gives user space the opportunity to fall back to copy-and-delete.
Signed-off-by: Michael Halcrow
---
fs/ubifs/dir.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 417fe0b29f23..6c5753a2f79f 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubif
20 matches
Mail list logo
