09 Jan, 2015

1 commit

  • commit b26bdde5bb27f3f900e25a95e33a0c476c8c2c48 upstream.

    When loading encrypted-keys module, if the last check of
    aes_get_sizes() in init_encrypted() fails, the driver just returns an
    error without unregistering its key type. This results in the stale
    entry in the list. In addition to memory leaks, this leads to a kernel
    crash when registering a new key type later.

    This patch fixes the problem by swapping the calls of aes_get_sizes()
    and register_key_type(), and releasing resources properly at the error
    paths.

    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163
    Signed-off-by: Takashi Iwai
    Signed-off-by: Mimi Zohar
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

02 Dec, 2014

3 commits

  • Since the keyring facility can be viewed as a cache (at least in some
    applications), the local expiration time on the key should probably be viewed
    as a 'needs updating after this time' property rather than an absolute 'anyone
    now wanting to use this object is out of luck' property.

    Since request_key() is the main interface for the usage of keys, this should
    update or replace an expired key rather than issuing EKEYEXPIRED if the local
    expiration has been reached (ie. it should refresh the cache).

    For absolute conditions where refreshing the cache probably doesn't help, the
    key can be negatively instantiated using KEYCTL_REJECT_KEY with EKEYEXPIRED
    given as the error to issue. This will still cause request_key() to return
    EKEYEXPIRED as that was explicitly set.

    In the future, if the key type has an update op available, we might want to
    upcall with the expired key and allow the upcall to update it. We would pass
    a different operation name (the first column in /etc/request-key.conf) to the
    request-key program.

    request_key() returning EKEYEXPIRED is causing an NFS problem which Chuck
    Lever describes thusly:

    After about 10 minutes, my NFSv4 functional tests fail because the
    ownership of the test files goes to "-2". Looking at /proc/keys
    shows that the id_resolv keys that map to my test user ID have
    expired. The ownership problem persists until the expired keys are
    purged from the keyring, and fresh keys are obtained.

    I bisected the problem to 3.13 commit b2a4df200d57 ("KEYS: Expand
    the capacity of a keyring"). This commit inadvertantly changes the
    API contract of the internal function keyring_search_aux().

    The root cause appears to be that b2a4df200d57 made "no state check"
    the default behavior. "No state check" means the keyring search
    iterator function skips checking the key's expiry timeout, and
    returns expired keys. request_key_and_link() depends on getting
    an -EAGAIN result code to know when to perform an upcall to refresh
    an expired key.

    This patch can be tested directly by:

    keyctl request2 user debug:fred a @s
    keyctl timeout %user:debug:fred 3
    sleep 4
    keyctl request2 user debug:fred a @s

    Without the patch, the last command gives error EKEYEXPIRED, but with the
    command it gives a new key.

    Reported-by: Carl Hetherington
    Reported-by: Chuck Lever
    Signed-off-by: David Howells
    Tested-by: Chuck Lever

    David Howells
     
  • Simplify KEYRING_SEARCH_{NO,DO}_STATE_CHECK flags to be two variations of the
    same flag. They are effectively mutually exclusive and one or the other
    should be provided, but not both.

    Keyring cycle detection and key possession determination are the only things
    that set NO_STATE_CHECK, except that neither flag really does anything there
    because neither purpose makes use of the keyring_search_iterator() function,
    but rather provides their own.

    For cycle detection we definitely want to check inside of expired keyrings,
    just so that we don't create a cycle we can't get rid of. Revoked keyrings
    are cleared at revocation time and can't then be reused, so shouldn't be a
    problem either way.

    For possession determination, we *might* want to validate each keyring before
    searching it: do you possess a key that's hidden behind an expired or just
    plain inaccessible keyring? Currently, the answer is yes. Note that you
    cannot, however, possess a key behind a revoked keyring because they are
    cleared on revocation.

    keyring_search() sets DO_STATE_CHECK, which is correct.

    request_key_and_link() currently doesn't specify whether to check the key
    state or not - but it should set DO_STATE_CHECK.

    key_get_instantiation_authkey() also currently doesn't specify whether to
    check the key state or not - but it probably should also set DO_STATE_CHECK.

    Signed-off-by: David Howells
    Tested-by: Chuck Lever

    David Howells
     
  • When a key description argument is imported into the kernel from userspace, as
    happens in add_key(), request_key(), KEYCTL_JOIN_SESSION_KEYRING,
    KEYCTL_SEARCH, the description is copied into a buffer up to PAGE_SIZE in size.
    PAGE_SIZE, however, is a variable quantity, depending on the arch. Fix this at
    4096 instead (ie. 4095 plus a NUL termination) and define a constant
    (KEY_MAX_DESC_SIZE) to this end.

    When reading the description back with KEYCTL_DESCRIBE, a PAGE_SIZE internal
    buffer is allocated into which the information and description will be
    rendered. This means that the description will get truncated if an extremely
    long description it has to be crammed into the buffer with the stringified
    information. There is no particular need to copy the description into the
    buffer, so just copy it directly to userspace in a separate operation.

    Reported-by: Christian Kastner
    Signed-off-by: David Howells
    Tested-by: Christian Kastner

    David Howells
     

12 Oct, 2014

1 commit

  • Pull security subsystem updates from James Morris.

    Mostly ima, selinux, smack and key handling updates.

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (65 commits)
    integrity: do zero padding of the key id
    KEYS: output last portion of fingerprint in /proc/keys
    KEYS: strip 'id:' from ca_keyid
    KEYS: use swapped SKID for performing partial matching
    KEYS: Restore partial ID matching functionality for asymmetric keys
    X.509: If available, use the raw subjKeyId to form the key description
    KEYS: handle error code encoded in pointer
    selinux: normalize audit log formatting
    selinux: cleanup error reporting in selinux_nlmsg_perm()
    KEYS: Check hex2bin()'s return when generating an asymmetric key ID
    ima: detect violations for mmaped files
    ima: fix race condition on ima_rdwr_violation_check and process_measurement
    ima: added ima_policy_flag variable
    ima: return an error code from ima_add_boot_aggregate()
    ima: provide 'ima_appraise=log' kernel option
    ima: move keyring initialization to ima_init()
    PKCS#7: Handle PKCS#7 messages that contain no X.509 certs
    PKCS#7: Better handling of unsupported crypto
    KEYS: Overhaul key identification when searching for asymmetric keys
    KEYS: Implement binary asymmetric key ID handling
    ...

    Linus Torvalds
     

17 Sep, 2014

7 commits

  • Make the key matching functions pointed to by key_match_data::cmp return bool
    rather than int.

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

    David Howells
     
  • 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
     
  • 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
     
  • Preparse the match data. This provides several advantages:

    (1) The preparser can reject invalid criteria up front.

    (2) The preparser can convert the criteria to binary data if necessary (the
    asymmetric key type really wants to do binary comparison of the key IDs).

    (3) The preparser can set the type of search to be performed. This means
    that it's not then a one-off setting in the key type.

    (4) The preparser can set an appropriate comparator function.

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

    David Howells
     
  • Merge in keyrings fixes for next:

    (1) Insert some missing 'static' annotations.

    Signed-off-by: David Howells

    David Howells
     
  • Reinstate the generation of EPERM for a key type name beginning with a '.' in
    a userspace call. Types whose name begins with a '.' are internal only.

    The test was removed by:

    commit a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d
    Author: Mimi Zohar
    Date: Thu May 22 14:02:23 2014 -0400
    Subject: KEYS: special dot prefixed keyring name bug fix

    I think we want to keep the restriction on type name so that userspace can't
    add keys of a special internal type.

    Note that removal of the test causes several of the tests in the keyutils
    testsuite to fail.

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal
    cc: Mimi Zohar

    David Howells
     
  • Fix missing statics (found by checker).

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

    David Howells
     

03 Sep, 2014

1 commit

  • Now that NFS client uses the kernel key ring facility to store the NFSv4
    id/gid mappings, the defaults for root_maxkeys and root_maxbytes need to be
    substantially increased.

    These values have been soak tested:

    https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c73

    Signed-off-by: Steve Dickson
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    Steve Dickson
     

06 Aug, 2014

1 commit

  • Pull security subsystem updates from James Morris:
    "In this release:

    - PKCS#7 parser for the key management subsystem from David Howells
    - appoint Kees Cook as seccomp maintainer
    - bugfixes and general maintenance across the subsystem"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (94 commits)
    X.509: Need to export x509_request_asymmetric_key()
    netlabel: shorter names for the NetLabel catmap funcs/structs
    netlabel: fix the catmap walking functions
    netlabel: fix the horribly broken catmap functions
    netlabel: fix a problem when setting bits below the previously lowest bit
    PKCS#7: X.509 certificate issuer and subject are mandatory fields in the ASN.1
    tpm: simplify code by using %*phN specifier
    tpm: Provide a generic means to override the chip returned timeouts
    tpm: missing tpm_chip_put in tpm_get_random()
    tpm: Properly clean sysfs entries in error path
    tpm: Add missing tpm_do_selftest to ST33 I2C driver
    PKCS#7: Use x509_request_asymmetric_key()
    Revert "selinux: fix the default socket labeling in sock_graft()"
    X.509: x509_request_asymmetric_keys() doesn't need string length arguments
    PKCS#7: fix sparse non static symbol warning
    KEYS: revert encrypted key change
    ima: add support for measuring and appraising firmware
    firmware_class: perform new LSM checks
    security: introduce kernel_fw_from_file hook
    PKCS#7: Missing inclusion of linux/err.h
    ...

    Linus Torvalds
     

28 Jul, 2014

1 commit

  • Commit fc7c70e "KEYS: struct key_preparsed_payload should have two
    payload pointers" erroneously modified encrypted-keys. This patch
    reverts the change to that file.

    Signed-off-by: Mimi Zohar
    Signed-off-by: David Howells

    Mimi Zohar
     

23 Jul, 2014

9 commits


19 Jul, 2014

1 commit

  • Provide a generic instantiation function for key types that use the preparse
    hook. This makes it easier to prereserve key quota before keyrings get locked
    to retain the new key.

    Signed-off-by: David Howells
    Acked-by: Steve Dickson
    Acked-by: Jeff Layton
    Reviewed-by: Sage Weil

    David Howells
     

18 Jul, 2014

1 commit

  • Special kernel keys, such as those used to hold DNS results for AFS, CIFS and
    NFS and those used to hold idmapper results for NFS, used to be
    'invalidateable' with key_revoke(). However, since the default permissions for
    keys were reduced:

    Commit: 96b5c8fea6c0861621051290d705ec2e971963f1
    KEYS: Reduce initial permissions on keys

    it has become impossible to do this.

    Add a key flag (KEY_FLAG_ROOT_CAN_INVAL) that will permit a key to be
    invalidated by root. This should not be used for system keyrings as the
    garbage collector will try and remove any invalidate key. For system keyrings,
    KEY_FLAG_ROOT_CAN_CLEAR can be used instead.

    After this, from userspace, keyctl_invalidate() and "keyctl invalidate" can be
    used by any possessor of CAP_SYS_ADMIN (typically root) to invalidate DNS and
    idmapper keys. Invalidated keys are immediately garbage collected and will be
    immediately rerequested if needed again.

    Signed-off-by: David Howells
    Tested-by: Steve Dickson

    David Howells
     

17 Jul, 2014

1 commit

  • Dot prefixed keyring names are supposed to be reserved for the
    kernel, but add_key() calls key_get_type_from_user(), which
    incorrectly verifies the 'type' field, not the 'description' field.
    This patch verifies the 'description' field isn't dot prefixed,
    when creating a new keyring, and removes the dot prefix test in
    key_get_type_from_user().

    Changelog v6:
    - whitespace and other cleanup

    Changelog v5:
    - Only prevent userspace from creating a dot prefixed keyring, not
    regular keys - Dmitry

    Reported-by: Dmitry Kasatkin
    Signed-off-by: Mimi Zohar
    Acked-by: David Howells

    Mimi Zohar
     

16 Jul, 2014

1 commit

  • The current "wait_on_bit" interface requires an 'action'
    function to be provided which does the actual waiting.
    There are over 20 such functions, many of them identical.
    Most cases can be satisfied by one of just two functions, one
    which uses io_schedule() and one which just uses schedule().

    So:
    Rename wait_on_bit and wait_on_bit_lock to
    wait_on_bit_action and wait_on_bit_lock_action
    to make it explicit that they need an action function.

    Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
    which are *not* given an action function but implicitly use
    a standard one.
    The decision to error-out if a signal is pending is now made
    based on the 'mode' argument rather than being encoded in the action
    function.

    All instances of the old wait_on_bit and wait_on_bit_lock which
    can use the new version have been changed accordingly and their
    action functions have been discarded.
    wait_on_bit{_lock} does not return any specific error code in the
    event of a signal so the caller must check for non-zero and
    interpolate their own error code as appropriate.

    The wait_on_bit() call in __fscache_wait_on_invalidate() was
    ambiguous as it specified TASK_UNINTERRUPTIBLE but used
    fscache_wait_bit_interruptible as an action function.
    David Howells confirms this should be uniformly
    "uninterruptible"

    The main remaining user of wait_on_bit{,_lock}_action is NFS
    which needs to use a freezer-aware schedule() call.

    A comment in fs/gfs2/glock.c notes that having multiple 'action'
    functions is useful as they display differently in the 'wchan'
    field of 'ps'. (and /proc/$PID/wchan).
    As the new bit_wait{,_io} functions are tagged "__sched", they
    will not show up at all, but something higher in the stack. So
    the distinction will still be visible, only with different
    function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
    gfs2/glock.c case).

    Since first version of this patch (against 3.15) two new action
    functions appeared, on in NFS and one in CIFS. CIFS also now
    uses an action function that makes the same freezer aware
    schedule call as NFS.

    Signed-off-by: NeilBrown
    Acked-by: David Howells (fscache, keys)
    Acked-by: Steven Whitehouse (gfs2)
    Acked-by: Peter Zijlstra
    Cc: Oleg Nesterov
    Cc: Steve French
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
    Signed-off-by: Ingo Molnar

    NeilBrown
     

24 Jun, 2014

1 commit


11 Jun, 2014

1 commit

  • Pull security layer updates from Serge Hallyn:
    "This is a merge of James Morris' security-next tree from 3.14 to
    yesterday's master, plus four patches from Paul Moore which are in
    linux-next, plus one patch from Mimi"

    * 'serge-next-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security:
    ima: audit log files opened with O_DIRECT flag
    selinux: conditionally reschedule in hashtab_insert while loading selinux policy
    selinux: conditionally reschedule in mls_convert_context while loading selinux policy
    selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES
    selinux: Report permissive mode in avc: denied messages.
    Warning in scanf string typing
    Smack: Label cgroup files for systemd
    Smack: Verify read access on file open - v3
    security: Convert use of typedef ctl_table to struct ctl_table
    Smack: bidirectional UDS connect check
    Smack: Correctly remove SMACK64TRANSMUTE attribute
    SMACK: Fix handling value==NULL in post setxattr
    bugfix patch for SMACK
    Smack: adds smackfs/ptrace interface
    Smack: unify all ptrace accesses in the smack
    Smack: fix the subject/object order in smack_ptrace_traceme()
    Minor improvement of 'smack_sb_kern_mount'
    smack: fix key permission verification
    KEYS: Move the flags representing required permission to linux/key.h

    Linus Torvalds
     

15 Apr, 2014

1 commit


14 Apr, 2014

2 commits


04 Apr, 2014

1 commit

  • Pull security subsystem updates from James Morris:
    "Apart from reordering the SELinux mmap code to ensure DAC is called
    before MAC, these are minor maintenance updates"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (23 commits)
    selinux: correctly label /proc inodes in use before the policy is loaded
    selinux: put the mmap() DAC controls before the MAC controls
    selinux: fix the output of ./scripts/get_maintainer.pl for SELinux
    evm: enable key retention service automatically
    ima: skip memory allocation for empty files
    evm: EVM does not use MD5
    ima: return d_name.name if d_path fails
    integrity: fix checkpatch errors
    ima: fix erroneous removal of security.ima xattr
    security: integrity: Use a more current logging style
    MAINTAINERS: email updates and other misc. changes
    ima: reduce memory usage when a template containing the n field is used
    ima: restore the original behavior for sending data with ima template
    Integrity: Pass commname via get_task_comm()
    fs: move i_readcount
    ima: use static const char array definitions
    security: have cap_dentry_init_security return error
    ima: new helper: file_inode(file)
    kernel: Mark function as static in kernel/seccomp.c
    capability: Use current logging styles
    ...

    Linus Torvalds
     

01 Apr, 2014

1 commit

  • Pull s390 compat wrapper rework from Heiko Carstens:
    "S390 compat system call wrapper simplification work.

    The intention of this work is to get rid of all hand written assembly
    compat system call wrappers on s390, which perform proper sign or zero
    extension, or pointer conversion of compat system call parameters.
    Instead all of this should be done with C code eg by using Al's
    COMPAT_SYSCALL_DEFINEx() macro.

    Therefore all common code and s390 specific compat system calls have
    been converted to the COMPAT_SYSCALL_DEFINEx() macro.

    In order to generate correct code all compat system calls may only
    have eg compat_ulong_t parameters, but no unsigned long parameters.
    Those patches which change parameter types from unsigned long to
    compat_ulong_t parameters are separate in this series, but shouldn't
    cause any harm.

    The only compat system calls which intentionally have 64 bit
    parameters (preadv64 and pwritev64) in support of the x86/32 ABI
    haven't been changed, but are now only available if an architecture
    defines __ARCH_WANT_COMPAT_SYS_PREADV64/PWRITEV64.

    System calls which do not have a compat variant but still need proper
    zero extension on s390, like eg "long sys_brk(unsigned long brk)" will
    get a proper wrapper function with the new s390 specific
    COMPAT_SYSCALL_WRAPx() macro:

    COMPAT_SYSCALL_WRAP1(brk, unsigned long, brk);

    which generates the following code (simplified):

    asmlinkage long sys_brk(unsigned long brk);
    asmlinkage long compat_sys_brk(long brk)
    {
    return sys_brk((u32)brk);
    }

    Given that the C file which contains all the COMPAT_SYSCALL_WRAP lines
    includes both linux/syscall.h and linux/compat.h, it will generate
    build errors, if the declaration of sys_brk() doesn't match, or if
    there exists a non-matching compat_sys_brk() declaration.

    In addition this will intentionally result in a link error if
    somewhere else a compat_sys_brk() function exists, which probably
    should have been used instead. Two more BUILD_BUG_ONs make sure the
    size and type of each compat syscall parameter can be handled
    correctly with the s390 specific macros.

    I converted the compat system calls step by step to verify the
    generated code is correct and matches the previous code. In fact it
    did not always match, however that was always a bug in the hand
    written asm code.

    In result we get less code, less bugs, and much more sanity checking"

    * 'compat' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (44 commits)
    s390/compat: add copyright statement
    compat: include linux/unistd.h within linux/compat.h
    s390/compat: get rid of compat wrapper assembly code
    s390/compat: build error for large compat syscall args
    mm/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
    kexec/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
    net/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
    ipc/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
    fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types
    ipc/compat: convert to COMPAT_SYSCALL_DEFINE
    fs/compat: convert to COMPAT_SYSCALL_DEFINE
    security/compat: convert to COMPAT_SYSCALL_DEFINE
    mm/compat: convert to COMPAT_SYSCALL_DEFINE
    net/compat: convert to COMPAT_SYSCALL_DEFINE
    kernel/compat: convert to COMPAT_SYSCALL_DEFINE
    fs/compat: optional preadv64/pwrite64 compat system calls
    ipc/compat_sys_msgrcv: change msgtyp type from long to compat_long_t
    s390/compat: partial parameter conversion within syscall wrappers
    s390/compat: automatic zero, sign and pointer conversion of syscalls
    s390/compat: add sync_file_range and fallocate compat syscalls
    ...

    Linus Torvalds
     

15 Mar, 2014

1 commit

  • Move the flags representing required permission to linux/key.h as the perm
    parameter of security_key_permission() is in terms of them - and not the
    permissions mask flags used in key->perm.

    Whilst we're at it:

    (1) Rename them to be KEY_NEED_xxx rather than KEY_xxx to avoid collisions
    with symbols in uapi/linux/input.h.

    (2) Don't use key_perm_t for a mask of required permissions, but rather limit
    it to the permissions mask attached to the key and arguments related
    directly to that.

    Signed-off-by: David Howells
    Tested-by: Dmitry Kasatkin

    David Howells
     

10 Mar, 2014

1 commit

  • This fixes CVE-2014-0102.

    The following command sequence produces an oops:

    keyctl new_session
    i=`keyctl newring _ses @s`
    keyctl link @s $i

    The problem is that search_nested_keyrings() sees two keyrings that have
    matching type and description, so keyring_compare_object() returns true.
    s_n_k() then passes the key to the iterator function -
    keyring_detect_cycle_iterator() - which *should* check to see whether this is
    the keyring of interest, not just one with the same name.

    Because assoc_array_find() will return one and only one match, I assumed that
    the iterator function would only see an exact match or never be called - but
    the iterator isn't only called from assoc_array_find()...

    The oops looks something like this:

    kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
    invalid opcode: 0000 [#1] SMP
    ...
    RIP: keyring_detect_cycle_iterator+0xe/0x1f
    ...
    Call Trace:
    search_nested_keyrings+0x76/0x2aa
    __key_link_check_live_key+0x50/0x5f
    key_link+0x4e/0x85
    keyctl_keyring_link+0x60/0x81
    SyS_keyctl+0x65/0xe4
    tracesys+0xdd/0xe2

    The fix is to make keyring_detect_cycle_iterator() check that the key it
    has is the key it was actually looking for rather than calling BUG_ON().

    A testcase has been included in the keyutils testsuite for this:

    http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790b

    Reported-by: Tommi Rantala
    Signed-off-by: David Howells
    Acked-by: James Morris
    Signed-off-by: Linus Torvalds

    David Howells
     

06 Mar, 2014

1 commit

  • Convert all compat system call functions where all parameter types
    have a size of four or less than four bytes, or are pointer types
    to COMPAT_SYSCALL_DEFINE.
    The implicit casts within COMPAT_SYSCALL_DEFINE will perform proper
    zero and sign extension to 64 bit of all parameters if needed.

    Signed-off-by: Heiko Carstens

    Heiko Carstens
     

06 Feb, 2014

1 commit


02 Dec, 2013

1 commit

  • 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