linux-ext4 - Re: [PATCH 1/3] ext4: require key for truncate(2) of encrypted file

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 13 Jun 2017 18:14:53 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     linux-fscrypt@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH 1/3] ext4: require key for truncate(2) of encrypted file

On Jun 13, 2017, at 5:47 PM, Eric Biggers <ebiggers3@...il.com> wrote:
> 
> From: Eric Biggers <ebiggers@...gle.com>
> 
> Currently, filesystems allow truncate(2) on an encrypted file without
> the encryption key.  However, it's impossible to correctly handle the
> case where the size being truncated to is not a multiple of the
> filesystem block size, because that would require decrypting the final
> block, zeroing the part beyond i_size, then encrypting the block.
> 
> As other modifications to encrypted file contents are prohibited without
> the key, just prohibit truncate(2) as well, making it fail with ENOKEY.

Out of curiosity, if an encrypted block is zero-filled at the end when
the key is unavailable, what would happen?  At worst this would result
in garbage at the end of the file when the zeroes are "decrypted"?

Is it possible to unlink files if they are encrypted without the key (if
the user has permission to write to the directory)?

Does file unlink result in the per-file crypto key being erased in the
inode, or is the inode just marked unused but not overwritten?  One of
the desirable features of per-file crypto is "secure erase" so that once
the inode is unlinked the crypto key is gone and there is no way to decrypt
the data after the fact, even if the filesystem/user key is later recovered.
If the per-file key is still sitting in the inode, then it may be possible
to decrypt the data long after the file was deleted if the key is later
compromised and the inode+data blocks were not re-used.

Cheers, Andreas

> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
> fs/ext4/inode.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 5cf82d03968c..baf8630de6a5 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5307,6 +5307,14 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr)
> 		loff_t oldsize = inode->i_size;
> 		int shrink = (attr->ia_size <= inode->i_size);
> 
> +		if (ext4_encrypted_inode(inode)) {
> +			error = fscrypt_get_encryption_info(inode);
> +			if (error)
> +				return error;
> +			if (!fscrypt_has_encryption_key(inode))
> +				return -ENOKEY;
> +		}
> +
> 		if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) {
> 			struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
> 
> --
> 2.13.1.508.gb3defc5cc-goog
> 

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)