Eric Lee / smarc-fsl-linux-kernel

12 Jan, 2017

1 commit

  • d259b6853   fscrypt: fix renaming and linking special files ... Browse Code »

    commit 42d97eb0ade31e1bc537d086842f5d6e766d9d51 upstream.

    Attempting to link a device node, named pipe, or socket file into an
    encrypted directory through rename(2) or link(2) always failed with
    EPERM. This happened because fscrypt_has_permitted_context() saw that
    the file was unencrypted and forbid creating the link. This behavior
    was unexpected because such files are never encrypted; only regular
    files, directories, and symlinks can be encrypted.

    To fix this, make fscrypt_has_permitted_context() always return true on
    special files.

    This will be covered by a test in my encryption xfstests patchset.

    Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
    Signed-off-by: Eric Biggers
    Reviewed-by: Richard Weinberger
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

15 Oct, 2016

1 commit

  • 8906a8223   fscrypto: lock inode while setting encryption policy ... Browse Code »

    i_rwsem needs to be acquired while setting an encryption policy so that
    concurrent calls to FS_IOC_SET_ENCRYPTION_POLICY are correctly
    serialized (especially the ->get_context() + ->set_context() pair), and
    so that new files cannot be created in the directory during or after the
    ->empty_dir() check.

    Signed-off-by: Eric Biggers
    Signed-off-by: Theodore Ts'o
    Reviewed-by: Richard Weinberger
    Cc: stable@vger.kernel.org

    Eric Biggers
     

10 Sep, 2016

3 commits

  • ba63f23d6   fscrypto: require write access to mount to set encryption policy ... Browse Code »

    Since setting an encryption policy requires writing metadata to the
    filesystem, it should be guarded by mnt_want_write/mnt_drop_write.
    Otherwise, a user could cause a write to a frozen or readonly
    filesystem. This was handled correctly by f2fs but not by ext4. Make
    fscrypt_process_policy() handle it rather than relying on the filesystem
    to get it right.

    Signed-off-by: Eric Biggers
    Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs}
    Signed-off-by: Theodore Ts'o
    Acked-by: Jaegeuk Kim

    Eric Biggers
     
  • 002ced4be   fscrypto: only allow setting encryption policy on directories ... Browse Code »

    The FS_IOC_SET_ENCRYPTION_POLICY ioctl allowed setting an encryption
    policy on nondirectory files. This was unintentional, and in the case
    of nonempty regular files did not behave as expected because existing
    data was not actually encrypted by the ioctl.

    In the case of ext4, the user could also trigger filesystem errors in
    ->empty_dir(), e.g. due to mismatched "directory" checksums when the
    kernel incorrectly tried to interpret a regular file as a directory.

    This bug affected ext4 with kernels v4.8-rc1 or later and f2fs with
    kernels v4.6 and later. It appears that older kernels only permitted
    directories and that the check was accidentally lost during the
    refactoring to share the file encryption code between ext4 and f2fs.

    This patch restores the !S_ISDIR() check that was present in older
    kernels.

    Signed-off-by: Eric Biggers
    Cc: stable@vger.kernel.org
    Signed-off-by: Theodore Ts'o

    Eric Biggers
     
  • 163ae1c6a   fscrypto: add authorization check for setting encryption policy ... Browse Code »

    On an ext4 or f2fs filesystem with file encryption supported, a user
    could set an encryption policy on any empty directory(*) to which they
    had readonly access. This is obviously problematic, since such a
    directory might be owned by another user and the new encryption policy
    would prevent that other user from creating files in their own directory
    (for example).

    Fix this by requiring inode_owner_or_capable() permission to set an
    encryption policy. This means that either the caller must own the file,
    or the caller must have the capability CAP_FOWNER.

    (*) Or also on any regular file, for f2fs v4.6 and later and ext4
    v4.8-rc1 and later; a separate bug fix is coming for that.

    Signed-off-by: Eric Biggers
    Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs}
    Signed-off-by: Theodore Ts'o

    Eric Biggers
     

18 Mar, 2016

1 commit

  • 0b81d0779   fs crypto: move per-file encryption from f2fs tree to fs/crypto ... Browse Code »

    This patch adds the renamed functions moved from the f2fs crypto files.

    1. definitions for per-file encryption used by ext4 and f2fs.

    2. crypto.c for encrypt/decrypt functions
    a. IO preparation:
    - fscrypt_get_ctx / fscrypt_release_ctx
    b. before IOs:
    - fscrypt_encrypt_page
    - fscrypt_decrypt_page
    - fscrypt_zeroout_range
    c. after IOs:
    - fscrypt_decrypt_bio_pages
    - fscrypt_pullback_bio_page
    - fscrypt_restore_control_page

    3. policy.c supporting context management.
    a. For ioctls:
    - fscrypt_process_policy
    - fscrypt_get_policy
    b. For context permission
    - fscrypt_has_permitted_context
    - fscrypt_inherit_context

    4. keyinfo.c to handle permissions
    - fscrypt_get_encryption_info
    - fscrypt_free_encryption_info

    5. fname.c to support filename encryption
    a. general wrapper functions
    - fscrypt_fname_disk_to_usr
    - fscrypt_fname_usr_to_disk
    - fscrypt_setup_filename
    - fscrypt_free_filename

    b. specific filename handling functions
    - fscrypt_fname_alloc_buffer
    - fscrypt_fname_free_buffer

    6. Makefile and Kconfig

    Cc: Al Viro
    Signed-off-by: Michael Halcrow
    Signed-off-by: Ildar Muslukhov
    Signed-off-by: Uday Savagaonkar
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Jaegeuk Kim

    Jaegeuk Kim