Eric Lee / smarc-fsl-linux-kernel

27 Oct, 2016

1 commit

  • 7df3e59c3   KEYS: Sort out big_key initialisation ... Browse Code »

    big_key has two separate initialisation functions, one that registers the
    key type and one that registers the crypto. If the key type fails to
    register, there's no problem if the crypto registers successfully because
    there's no way to reach the crypto except through the key type.

    However, if the key type registers successfully but the crypto does not,
    big_key_rng and big_key_blkcipher may end up set to NULL - but the code
    neither checks for this nor unregisters the big key key type.

    Furthermore, since the key type is registered before the crypto, it is
    theoretically possible for the kernel to try adding a big_key before the
    crypto is set up, leading to the same effect.

    Fix this by merging big_key_crypto_init() and big_key_init() and calling
    the resulting function late. If they're going to be encrypted, we
    shouldn't be creating big_keys before we have the facilities to do the
    encryption available. The key type registration is also moved after the
    crypto initialisation.

    The fix also includes message printing on failure.

    If the big_key type isn't correctly set up, simply doing:

    dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s

    ought to cause an oops.

    Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
    Signed-off-by: David Howells
    cc: Peter Hlavaty
    cc: Kirill Marinushkin
    cc: Artem Savkov
    cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     

24 Jun, 2016

1 commit

13 Apr, 2016

1 commit

18 Feb, 2016

1 commit

  • a1f2bdf33   security/keys: make big_key.c explicitly non-modular ... Browse Code »

    The Kconfig currently controlling compilation of this code is:

    config BIG_KEYS
    bool "Large payload keys"

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the modular code that is essentially orphaned, so that
    when reading the driver there is no doubt it is builtin-only.

    Since module_init translates to device_initcall in the non-modular
    case, the init ordering remains unchanged with this commit.

    We also delete the MODULE_LICENSE tag since all that information
    is already contained at the top of the file in the comments.

    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: keyrings@vger.kernel.org
    Cc: linux-security-module@vger.kernel.org
    Signed-off-by: Paul Gortmaker
    Signed-off-by: David Howells

    Paul Gortmaker
     

21 Oct, 2015

1 commit

  • 146aa8b14   KEYS: Merge the type-specific data with the payload data ... Browse Code »

    Merge the type-specific data with the payload data into one four-word chunk
    as it seems pointless to keep them separate.

    Use user_key_payload() for accessing the payloads of overloaded
    user-defined keys.

    Signed-off-by: David Howells
    cc: linux-cifs@vger.kernel.org
    cc: ecryptfs@vger.kernel.org
    cc: linux-ext4@vger.kernel.org
    cc: linux-f2fs-devel@lists.sourceforge.net
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-ima-devel@lists.sourceforge.net

    David Howells
     

17 Sep, 2014

2 commits

  • c06cfb08b   KEYS: Remove key_type::match in favour of overriding default by match_preparse ... Browse Code »

    A previous patch added a ->match_preparse() method to the key type. This is
    allowed to override the function called by the iteration algorithm.
    Therefore, we can just set a default that simply checks for an exact match of
    the key description with the original criterion data and allow match_preparse
    to override it as needed.

    The key_type::match op is then redundant and can be removed, as can the
    user_match() function.

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal

    David Howells
     
  • 614d8c390   KEYS: Remove key_type::def_lookup_type ... Browse Code »

    Remove key_type::def_lookup_type as it's no longer used. The information now
    defaults to KEYRING_SEARCH_LOOKUP_DIRECT but may be overridden by
    type->match_preparse().

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal

    David Howells
     

23 Jul, 2014

1 commit

02 Dec, 2013

1 commit

  • c72770909   security: shmem: implement kernel private shmem inodes ... Browse Code »

    We have a problem where the big_key key storage implementation uses a
    shmem backed inode to hold the key contents. Because of this detail of
    implementation LSM checks are being done between processes trying to
    read the keys and the tmpfs backed inode. The LSM checks are already
    being handled on the key interface level and should not be enforced at
    the inode level (since the inode is an implementation detail, not a
    part of the security model)

    This patch implements a new function shmem_kernel_file_setup() which
    returns the equivalent to shmem_file_setup() only the underlying inode
    has S_PRIVATE set. This means that all LSM checks for the inode in
    question are skipped. It should only be used for kernel internal
    operations where the inode is not exposed to userspace without proper
    LSM checking. It is possible that some other users of
    shmem_file_setup() should use the new interface, but this has not been
    explored.

    Reproducing this bug is a little bit difficult. The steps I used on
    Fedora are:

    (1) Turn off selinux enforcing:

    setenforce 0

    (2) Create a huge key

    k=`dd if=/dev/zero bs=8192 count=1 | keyctl padd big_key test-key @s`

    (3) Access the key in another context:

    runcon system_u:system_r:httpd_t:s0-s0:c0.c1023 keyctl print $k >/dev/null

    (4) Examine the audit logs:

    ausearch -m AVC -i --subject httpd_t | audit2allow

    If the last command's output includes a line that looks like:

    allow httpd_t user_tmpfs_t:file { open read };

    There was an inode check between httpd and the tmpfs filesystem. With
    this patch no such denial will be seen. (NOTE! you should clear your
    audit log if you have tested for this previously)

    (Please return you box to enforcing)

    Signed-off-by: Eric Paris
    Signed-off-by: David Howells
    cc: Hugh Dickins
    cc: linux-mm@kvack.org

    Eric Paris
     

14 Nov, 2013

1 commit

  • 97826c821   KEYS: Fix error handling in big_key instantiation ... Browse Code »

    In the big_key_instantiate() function we return 0 if kernel_write() returns us
    an error rather than returning an error. This can potentially lead to
    dentry_open() giving a BUG when called from big_key_read() with an unset
    tmpfile path.

    ------------[ cut here ]------------
    kernel BUG at fs/open.c:798!
    ...
    RIP: 0010:[] dentry_open+0xd1/0xe0
    ...
    Call Trace:
    [] big_key_read+0x55/0x100
    [] keyctl_read_key+0xb4/0xe0
    [] SyS_keyctl+0xf8/0x1d0
    [] system_call_fastpath+0x16/0x1b

    Signed-off-by: David Howells
    Reviewed-by: Stephen Gallagher

    David Howells
     

30 Oct, 2013

1 commit

24 Sep, 2013

1 commit