linux-ext4 - Re: [PATCH 4/4] fscrypt: move the policy flags and encryption mode definitions to uapi header

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] [day] [month] [year] [list]

Date:   Tue, 29 Nov 2016 13:30:33 -0800
From:   Eric Biggers <ebiggers@...gle.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Linux Filesystem Development List <linux-fsdevel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        jaegeuk@...nel.org, Michael Halcrow <mhalcrow@...gle.com>
Subject: Re: [PATCH 4/4] fscrypt: move the policy flags and encryption mode
 definitions to uapi header

On Sat, Nov 26, 2016 at 11:41:55PM -0500, Theodore Ts'o wrote:
> These constants are part of the UAPI, so they belong in
> include/uapi/linux/fs.h instead of include/linux/fscrypto.h
> 
> Signed-off-by: Theodore Ts'o <tytso@....edu>
> ---
>  include/linux/fscrypto.h | 14 --------------
>  include/uapi/linux/fs.h  | 14 ++++++++++++++
>  2 files changed, 14 insertions(+), 14 deletions(-)
> 

This looks fine to me.  I had wanted to do this a while back, but there was some
talk about exposing the modes under names that hide the specific algorithms,
like "CRYPT_SW_V1", with the assumption being that users shouldn't have to know
about any specific modes but rather simply choose the modes with the highest
version numbers, which would also be the most secure.  But I wasn't really
convinced by that argument because people might add or use specific modes for
reasons other than security, such as hardware support on a certain platform.
And I think a better solution to the "use the most secure mode the kernel knows
about" problem would be to implement a special mode like
FS_ENCRYPTION_MODE_MOST_SECURE which the kernel would translate into its
preferred mode when setting an encryption policy.

Mike, do you have a different opinion?

I should also mention that the UAPI header is also missing struct fscrypt_key
and its the definitions FS_MAX_KEY_SIZE, FS_KEY_DESC_PREFIX, and
FS_KEY_DESC_PREFIX_SIZE.  I think those should be moved to the UAPI header too,
though that can be a separate patch.

Reviewed-by: Eric Biggers <ebiggers@...gle.com>

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html