14 Jun, 2018

1 commit

  • The changes to automatically test for working stack protector compiler
    support in the Kconfig files removed the special STACKPROTECTOR_AUTO
    option that picked the strongest stack protector that the compiler
    supported.

    That was all a nice cleanup - it makes no sense to have the AUTO case
    now that the Kconfig phase can just determine the compiler support
    directly.

    HOWEVER.

    It also meant that doing "make oldconfig" would now _disable_ the strong
    stackprotector if you had AUTO enabled, because in a legacy config file,
    the sane stack protector configuration would look like

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_NONE is not set
    # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_STACKPROTECTOR_AUTO=y

    and when you ran this through "make oldconfig" with the Kbuild changes,
    it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
    been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
    CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
    used to be disabled (because it was really enabled by AUTO), and would
    disable it in the new config, resulting in:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    That's dangerously subtle - people could suddenly find themselves with
    the weaker stack protector setup without even realizing.

    The solution here is to just rename not just the old RECULAR stack
    protector option, but also the strong one. This does that by just
    removing the CC_ prefix entirely for the user choices, because it really
    is not about the compiler support (the compiler support now instead
    automatially impacts _visibility_ of the options to users).

    This results in "make oldconfig" actually asking the user for their
    choice, so that we don't have any silent subtle security model changes.
    The end result would generally look like this:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_STACKPROTECTOR=y
    CONFIG_STACKPROTECTOR_STRONG=y
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    where the "CC_" versions really are about internal compiler
    infrastructure, not the user selections.

    Acked-by: Masahiro Yamada
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 May, 2018

1 commit


21 Mar, 2018

1 commit


27 Feb, 2018

1 commit


23 Feb, 2018

1 commit


09 Jan, 2018

1 commit

  • This patch updates the documentation with the observations that led
    to commit bdcf0a423ea1 ("kernel: make groups_sort calling a
    responsibility group_info allocators") and the new behaviour required.
    Specifically that groups_sort() should be called on a new group_list
    before set_groups() or set_current_groups() is called.

    Signed-off-by: NeilBrown
    [jc: use proper :c:func: references]
    Signed-off-by: Jonathan Corbet

    NeilBrown
     

22 Dec, 2017

1 commit

  • Hashing addresses printed with printk specifier %p was implemented
    recently. During development a number of issues were raised regarding
    leaking kernel addresses to userspace. Other documentation was updated but
    security/self-protection missed out.

    Add self-protection documentation regarding printing kernel addresses.

    Signed-off-by: Tobin C. Harding
    Signed-off-by: Jonathan Corbet

    Tobin C. Harding
     

16 Nov, 2017

1 commit

  • When keyctl_read() is passed a buffer that is too small, the behavior is
    inconsistent. Some key types will fill as much of the buffer as
    possible, while others won't copy anything. Moreover, the in-kernel
    documentation contradicted the man page on this point.

    Update the in-kernel documentation to say that this point is
    unspecified.

    Signed-off-by: Eric Biggers
    Signed-off-by: David Howells

    Eric Biggers
     

13 Oct, 2017

1 commit


31 Aug, 2017

1 commit


25 Aug, 2017

1 commit


14 Jul, 2017

1 commit


19 May, 2017

15 commits


05 Apr, 2017

4 commits

  • SP800-56A defines the use of DH with key derivation function based on a
    counter. The input to the KDF is defined as (DH shared secret || other
    information). The value for the "other information" is to be provided by
    the caller.

    The KDF is implemented using the hash support from the kernel crypto API.
    The implementation uses the symmetric hash support as the input to the
    hash operation is usually very small. The caller is allowed to specify
    the hash name that he wants to use to derive the key material allowing
    the use of all supported hashes provided with the kernel crypto API.

    As the KDF implements the proper truncation of the DH shared secret to
    the requested size, this patch fills the caller buffer up to its size.

    The patch is tested with a new test added to the keyutils user space
    code which uses a CAVS test vector testing the compliance with
    SP800-56A.

    Signed-off-by: Stephan Mueller
    Signed-off-by: David Howells

    Stephan Mueller
     
  • Keyrings recently gained restrict_link capabilities that allow
    individual keys to be validated prior to linking. This functionality
    was only available using internal kernel APIs.

    With the KEYCTL_RESTRICT_KEYRING command existing keyrings can be
    configured to check the content of keys before they are linked, and
    then allow or disallow linkage of that key to the keyring.

    To restrict a keyring, call:

    keyctl(KEYCTL_RESTRICT_KEYRING, key_serial_t keyring, const char *type,
    const char *restriction)

    where 'type' is the name of a registered key type and 'restriction' is a
    string describing how key linkage is to be restricted. The restriction
    option syntax is specific to each key type.

    Signed-off-by: Mat Martineau

    Mat Martineau
     
  • The restrict_link functions used to validate keys as they are linked
    to a keyring can be associated with specific key types. Each key type
    may be loaded (or not) at runtime, so lookup of restrict_link
    functions needs to be part of the key type implementation to ensure
    that the requested keys can be examined.

    Signed-off-by: Mat Martineau

    Mat Martineau
     
  • Replace struct key's restrict_link function pointer with a pointer to
    the new struct key_restriction. The structure contains pointers to the
    restriction function as well as relevant data for evaluating the
    restriction.

    The garbage collector checks restrict_link->keytype when key types are
    unregistered. Restrictions involving a removed key type are converted
    to use restrict_link_reject so that restrictions cannot be removed by
    unregistering key types.

    Signed-off-by: Mat Martineau

    Mat Martineau
     

04 Apr, 2017

2 commits

  • The first argument to the restrict_link_func_t functions was a keyring
    pointer. These functions are called by the key subsystem with this
    argument set to the destination keyring, but restrict_link_by_signature
    expects a pointer to the relevant trusted keyring.

    Restrict functions may need something other than a single struct key
    pointer to allow or reject key linkage, so the data used to make that
    decision (such as the trust keyring) is moved to a new, fourth
    argument. The first argument is now always the destination keyring.

    Signed-off-by: Mat Martineau

    Mat Martineau
     
  • This pointer type needs to be returned from a lookup function, and
    without a typedef the syntax gets cumbersome.

    Signed-off-by: Mat Martineau

    Mat Martineau
     

02 Mar, 2017

1 commit

  • rcu_dereference_key() and user_key_payload() are currently being used in
    two different, incompatible ways:

    (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
    to protect the key.

    (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
    used to protect the key and the may be being modified.

    Fix this by splitting both of the key wrappers to produce:

    (1) RCU accessors for keys when caller has the key semaphore locked:

    dereference_key_locked()
    user_key_payload_locked()

    (2) RCU accessors for keys when caller holds the RCU read lock:

    dereference_key_rcu()
    user_key_payload_rcu()

    This should fix following warning in the NFS idmapper

    ===============================
    [ INFO: suspicious RCU usage. ]
    4.10.0 #1 Tainted: G W
    -------------------------------
    ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
    other info that might help us debug this:
    rcu_scheduler_active = 2, debug_locks = 0
    1 lock held by mount.nfs/5987:
    #0: (rcu_read_lock){......}, at: [] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
    stack backtrace:
    CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G W 4.10.0 #1
    Call Trace:
    dump_stack+0xe8/0x154 (unreliable)
    lockdep_rcu_suspicious+0x140/0x190
    nfs_idmap_get_key+0x380/0x420 [nfsv4]
    nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
    decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
    decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
    nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
    rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
    call_decode+0x29c/0x910 [sunrpc]
    __rpc_execute+0x140/0x8f0 [sunrpc]
    rpc_run_task+0x170/0x200 [sunrpc]
    nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
    _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
    nfs4_lookup_root+0xe0/0x350 [nfsv4]
    nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
    nfs4_find_root_sec+0xc4/0x100 [nfsv4]
    nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
    nfs4_get_rootfh+0x6c/0x190 [nfsv4]
    nfs4_server_common_setup+0xc4/0x260 [nfsv4]
    nfs4_create_server+0x278/0x3c0 [nfsv4]
    nfs4_remote_mount+0x50/0xb0 [nfsv4]
    mount_fs+0x74/0x210
    vfs_kern_mount+0x78/0x220
    nfs_do_root_mount+0xb0/0x140 [nfsv4]
    nfs4_try_mount+0x60/0x100 [nfsv4]
    nfs_fs_mount+0x5ec/0xda0 [nfs]
    mount_fs+0x74/0x210
    vfs_kern_mount+0x78/0x220
    do_mount+0x254/0xf70
    SyS_mount+0x94/0x100
    system_call+0x38/0xe0

    Reported-by: Jan Stancek
    Signed-off-by: David Howells
    Tested-by: Jan Stancek
    Signed-off-by: James Morris

    David Howells
     

22 Feb, 2017

1 commit


08 Feb, 2017

2 commits

  • Both of these options are poorly named. The features they provide are
    necessary for system security and should not be considered debug only.
    Change the names to CONFIG_STRICT_KERNEL_RWX and
    CONFIG_STRICT_MODULE_RWX to better describe what these options do.

    Signed-off-by: Laura Abbott
    Acked-by: Jessica Yu
    Signed-off-by: Kees Cook

    Laura Abbott
     
  • There are multiple architectures that support CONFIG_DEBUG_RODATA and
    CONFIG_SET_MODULE_RONX. These options also now have the ability to be
    turned off at runtime. Move these to an architecture independent
    location and make these options def_bool y for almost all of those
    arches.

    Signed-off-by: Laura Abbott
    Acked-by: Ingo Molnar
    Acked-by: Heiko Carstens
    Signed-off-by: Kees Cook

    Laura Abbott
     

19 Jan, 2017

1 commit

  • I am still tired of having to find indirect ways to determine
    what security modules are active on a system. I have added
    /sys/kernel/security/lsm, which contains a comma separated
    list of the active security modules. No more groping around
    in /proc/filesystems or other clever hacks.

    Unchanged from previous versions except for being updated
    to the latest security next branch.

    Signed-off-by: Casey Schaufler
    Acked-by: John Johansen
    Acked-by: Paul Moore
    Acked-by: Kees Cook
    Signed-off-by: James Morris

    Casey Schaufler
     

15 Dec, 2016

1 commit

  • Pull security subsystem updates from James Morris:
    "Generally pretty quiet for this release. Highlights:

    Yama:
    - allow ptrace access for original parent after re-parenting

    TPM:
    - add documentation
    - many bugfixes & cleanups
    - define a generic open() method for ascii & bios measurements

    Integrity:
    - Harden against malformed xattrs

    SELinux:
    - bugfixes & cleanups

    Smack:
    - Remove unnecessary smack_known_invalid label
    - Do not apply star label in smack_setprocattr hook
    - parse mnt opts after privileges check (fixes unpriv DoS vuln)"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (56 commits)
    Yama: allow access for the current ptrace parent
    tpm: adjust return value of tpm_read_log
    tpm: vtpm_proxy: conditionally call tpm_chip_unregister
    tpm: Fix handling of missing event log
    tpm: Check the bios_dir entry for NULL before accessing it
    tpm: return -ENODEV if np is not set
    tpm: cleanup of printk error messages
    tpm: replace of_find_node_by_name() with dev of_node property
    tpm: redefine read_log() to handle ACPI/OF at runtime
    tpm: fix the missing .owner in tpm_bios_measurements_ops
    tpm: have event log use the tpm_chip
    tpm: drop tpm1_chip_register(/unregister)
    tpm: replace dynamically allocated bios_dir with a static array
    tpm: replace symbolic permission with octal for securityfs files
    char: tpm: fix kerneldoc tpm2_unseal_trusted name typo
    tpm_tis: Allow tpm_tis to be bound using DT
    tpm, tpm_vtpm_proxy: add kdoc comments for VTPM_PROXY_IOC_NEW_DEV
    tpm: Only call pm_runtime_get_sync if device has a parent
    tpm: define a generic open() method for ascii & bios measurements
    Documentation: tpm: add the Physical TPM device tree binding documentation
    ...

    Linus Torvalds
     

17 Nov, 2016

1 commit