27 Jul, 2016

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "Some big changes this month, headlined by the addition of a new
    formatted documentation mechanism based on the Sphinx system.

    The objectives here are to make it easier to create better-integrated
    (and more attractive) documents while (eventually) dumping our
    one-of-a-kind, cobbled-together system for something that is widely
    used and maintained by others. There's a fair amount of information
    what's being done, why, and how to use it in:

    https://lwn.net/Articles/692704/
    https://lwn.net/Articles/692705/

    Closer to home, Documentation/kernel-documentation.rst describes how
    it works.

    For now, the new system exists alongside the old one; you should soon
    see the GPU documentation converted over in the DRM pull and some
    significant media conversion work as well. Once all the docs have
    been moved over and we're convinced that the rough edges (of which are
    are a few) have been smoothed over, the DocBook-based stuff should go
    away.

    Primary credit is to Jani Nikula for doing the heavy lifting to make
    this stuff actually work; there has also been notable effort from
    Markus Heiser, Daniel Vetter, and Mauro Carvalho Chehab.

    Expect a couple of conflicts on the new index.rst file over the course
    of the merge window; they are trivially resolvable. That file may be
    a bit of a conflict magnet in the short term, but I don't expect that
    situation to last for any real length of time.

    Beyond that, of course, we have the usual collection of tweaks,
    updates, and typo fixes"

    * tag 'docs-for-linus' of git://git.lwn.net/linux: (77 commits)
    doc-rst: kernel-doc: fix handling of address_space tags
    Revert "doc/sphinx: Enable keep_warnings"
    doc-rst: kernel-doc directive, fix state machine reporter
    docs: deprecate kernel-doc-nano-HOWTO.txt
    doc/sphinx: Enable keep_warnings
    Documentation: add watermark_scale_factor to the list of vm systcl file
    kernel-doc: Fix up warning output
    docs: Get rid of some kernel-documentation warnings
    doc-rst: add an option to ignore DocBooks when generating docs
    workqueue: Fix a typo in workqueue.txt
    Doc: ocfs: Fix typo in filesystems/ocfs2-online-filecheck.txt
    Documentation/sphinx: skip build if user requested specific DOCBOOKS
    Documentation: add cleanmediadocs to the documentation targets
    Add .pyc files to .gitignore
    Doc: PM: Fix a typo in intel_powerclamp.txt
    doc-rst: flat-table directive - initial implementation
    Documentation: add meta-documentation for Sphinx and kernel-doc
    Documentation: tiny typo fix in usb/gadget_multi.txt
    Documentation: fix wrong value in md.txt
    bcache: documentation formatting, edited for clarity, stripe alignment notes
    ...

    Linus Torvalds
     

10 Jun, 2016

1 commit

  • The meaning of "leak" can be both "untracked resource allocation" and
    "memory content disclosure". This document's use was entirely of the
    latter meaning, so avoid the confusion by using the Common Weakness
    Enumeration name for this: Information Exposure (CWE-200). Additionally
    adds a section on structure randomization.

    Signed-off-by: Kees Cook
    Signed-off-by: Jonathan Corbet

    Kees Cook
     

03 Jun, 2016

1 commit

  • The values computed during Diffie-Hellman key exchange are often used
    in combination with key derivation functions to create cryptographic
    keys. Add a placeholder for a later implementation to configure a
    key derivation function that will transform the Diffie-Hellman
    result returned by the KEYCTL_DH_COMPUTE command.

    [This patch was stripped down from a patch produced by Mat Martineau that
    had a bug in the compat code - so for the moment Stephan's patch simply
    requires that the placeholder argument must be NULL]

    Original-signed-off-by: Mat Martineau
    Signed-off-by: Stephan Mueller
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    Stephan Mueller
     

20 May, 2016

1 commit

  • Pull Documentation updates from Jon Corbet:
    "A bit busier this time around.

    The most interesting thing (IMO) this time around is some beginning
    infrastructural work to allow documents to be written using
    restructured text. Maybe someday, in a galaxy far far away, we'll be
    able to eliminate the DocBook dependency and have a much better
    integrated set of kernel docs. Someday.

    Beyond that, there's a new document on security hardening from Kees,
    the movement of some sample code over to samples/, a number of
    improvements to the serial docs from Geert, and the usual collection
    of corrections, typo fixes, etc"

    * tag 'docs-for-linus' of git://git.lwn.net/linux: (55 commits)
    doc: self-protection: provide initial details
    serial: doc: Use port->state instead of info
    serial: doc: Always refer to tty_port->mutex
    Documentation: vm: Spelling s/paltform/platform/g
    Documentation/memcg: update kmem limit doc as codes behavior
    docproc: print a comment about autogeneration for rst output
    docproc: add support for reStructuredText format via --rst option
    docproc: abstract terminating lines at first space
    docproc: abstract docproc directive detection
    docproc: reduce unnecessary indentation
    docproc: add variables for subcommand and filename
    kernel-doc: use rst C domain directives and references for types
    kernel-doc: produce RestructuredText output
    kernel-doc: rewrite usage description, remove duplicated comments
    Doc: correct the location of sysrq.c
    Documentation: fix common spelling mistakes
    samples: v4l: from Documentation to samples directory
    samples: connector: from Documentation to samples directory
    Documentation: xillybus: fix spelling mistake
    Documentation: x86: fix spelling mistakes
    ...

    Linus Torvalds
     

18 May, 2016

1 commit

  • This document attempts to codify the intent around kernel self-protection
    along with discussion of both existing and desired technologies, with
    attention given to the rationale behind them, and the expectations of
    their usage.

    Signed-off-by: Kees Cook
    Reviewed-by: Randy Dunlap
    [jc: applied fixes suggested by Randy]
    Reviewed-by: Greg Kroah-Hartman
    Signed-off-by: Jonathan Corbet

    Kees Cook
     

06 May, 2016

1 commit


05 May, 2016

1 commit

  • Here's a set of patches that changes how certificates/keys are determined
    to be trusted. That's currently a two-step process:

    (1) Up until recently, when an X.509 certificate was parsed - no matter
    the source - it was judged against the keys in .system_keyring,
    assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set
    upon them.

    This has just been changed such that any key in the .ima_mok keyring,
    if configured, may also be used to judge the trustworthiness of a new
    certificate, whether or not the .ima_mok keyring is meant to be
    consulted for whatever process is being undertaken.

    If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED
    will be set upon a key it is loaded into (if it is loaded into one),
    no matter what the key is going to be loaded for.

    (2) If an X.509 certificate is loaded into a key, then that key - if
    KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring
    with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the
    system keyring only, but has been extended to various IMA keyrings.
    A user can at will link any key marked KEY_FLAG_TRUSTED into any
    keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks
    permit it.

    These patches change that:

    (1) Trust becomes a matter of consulting the ring of trusted keys supplied
    when the trust is evaluated only.

    (2) Every keyring can be supplied with its own manager function to
    restrict what may be added to that keyring. This is called whenever a
    key is to be linked into the keyring to guard against a key being
    created in one keyring and then linked across.

    This function is supplied with the keyring and the key type and
    payload[*] of the key being linked in for use in its evaluation. It
    is permitted to use other data also, such as the contents of other
    keyrings such as the system keyrings.

    [*] The type and payload are supplied instead of a key because as an
    optimisation this function may be called whilst creating a key and
    so may reject the proposed key between preparse and allocation.

    (3) A default manager function is provided that permits keys to be
    restricted to only asymmetric keys that are vouched for by the
    contents of the system keyring.

    A second manager function is provided that just rejects with EPERM.

    (4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available
    so that the kernel can initialise keyrings with keys that form the
    root of the trust relationship.

    (5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with
    key_preparsed_payload::trusted.

    This change also makes it possible in future for userspace to create a private
    set of trusted keys and then to have it sealed by setting a manager function
    where the private set is wholly independent of the kernel's trust
    relationships.

    Further changes in the set involve extracting certain IMA special keyrings
    and making them generally global:

    (*) .system_keyring is renamed to .builtin_trusted_keys and remains read
    only. It carries only keys built in to the kernel. It may be where
    UEFI keys should be loaded - though that could better be the new
    secondary keyring (see below) or a separate UEFI keyring.

    (*) An optional secondary system keyring (called .secondary_trusted_keys)
    is added to replace the IMA MOK keyring.

    (*) Keys can be added to the secondary keyring by root if the keys can
    be vouched for by either ring of system keys.

    (*) Module signing and kexec only use .builtin_trusted_keys and do not use
    the new secondary keyring.

    (*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as
    that's the only type currently permitted on the system keyrings.

    (*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
    is provided to allow keys to be added to IMA keyrings, subject to the
    restriction that such keys are validly signed by a key already in the
    system keyrings.

    If this option is enabled, but secondary keyrings aren't, additions to
    the IMA keyrings will be restricted to signatures verifiable by keys in
    the builtin system keyring only.

    Signed-off-by: David Howells

    David Howells
     

21 Apr, 2016

1 commit

  • This LSM enforces that kernel-loaded files (modules, firmware, etc)
    must all come from the same filesystem, with the expectation that
    such a filesystem is backed by a read-only device such as dm-verity
    or CDROM. This allows systems that have a verified and/or unchangeable
    filesystem to enforce module and firmware loading restrictions without
    needing to sign the files individually.

    Signed-off-by: Kees Cook
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Kees Cook
     

13 Apr, 2016

1 commit

  • This adds userspace access to Diffie-Hellman computations through a
    new keyctl() syscall command to calculate shared secrets or public
    keys using input parameters stored in the keyring.

    Input key ids are provided in a struct due to the current 5-arg limit
    for the keyctl syscall. Only user keys are supported in order to avoid
    exposing the content of logon or encrypted keys.

    The output is written to the provided buffer, based on the assumption
    that the values are only needed in userspace.

    Future support for other types of key derivation would involve a new
    command, like KEYCTL_ECDH_COMPUTE.

    Once Diffie-Hellman support is included in the crypto API, this code
    can be converted to use the crypto API to take advantage of possible
    hardware acceleration and reduce redundant code.

    Signed-off-by: Mat Martineau
    Signed-off-by: David Howells

    Mat Martineau
     

12 Apr, 2016

1 commit

  • Add a facility whereby proposed new links to be added to a keyring can be
    vetted, permitting them to be rejected if necessary. This can be used to
    block public keys from which the signature cannot be verified or for which
    the signature verification fails. It could also be used to provide
    blacklisting.

    This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.

    To this end:

    (1) A function pointer is added to the key struct that, if set, points to
    the vetting function. This is called as:

    int (*restrict_link)(struct key *keyring,
    const struct key_type *key_type,
    unsigned long key_flags,
    const union key_payload *key_payload),

    where 'keyring' will be the keyring being added to, key_type and
    key_payload will describe the key being added and key_flags[*] can be
    AND'ed with KEY_FLAG_TRUSTED.

    [*] This parameter will be removed in a later patch when
    KEY_FLAG_TRUSTED is removed.

    The function should return 0 to allow the link to take place or an
    error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
    link.

    The pointer should not be set directly, but rather should be set
    through keyring_alloc().

    Note that if called during add_key(), preparse is called before this
    method, but a key isn't actually allocated until after this function
    is called.

    (2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
    key_create_or_update() or key_instantiate_and_link() to bypass the
    restriction check.

    (3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
    with this restriction emplaced can be considered 'trustworthy' by
    virtue of being in the keyring when that keyring is consulted.

    (4) key_alloc() and keyring_alloc() take an extra argument that will be
    used to set restrict_link in the new key. This ensures that the
    pointer is set before the key is published, thus preventing a window
    of unrestrictedness. Normally this argument will be NULL.

    (5) As a temporary affair, keyring_restrict_trusted_only() is added. It
    should be passed to keyring_alloc() as the extra argument instead of
    setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
    a later patch with functions that look in the appropriate places for
    authoritative keys.

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

    David Howells
     

20 Dec, 2015

2 commits

  • TPM2 supports authorization policies, which are essentially
    combinational logic statements repsenting the conditions where the data
    can be unsealed based on the TPM state. This patch enables to use
    authorization policies to seal trusted keys.

    Two following new options have been added for trusted keys:

    * 'policydigest=': provide an auth policy digest for sealing.
    * 'policyhandle=': provide a policy session handle for unsealing.

    If 'hash=' option is supplied after 'policydigest=' option, this
    will result an error because the state of the option would become
    mixed.

    Signed-off-by: Jarkko Sakkinen
    Tested-by: Colin Ian King
    Reviewed-by: Mimi Zohar
    Acked-by: Peter Huewe

    Jarkko Sakkinen
     
  • Added 'hash=' option for selecting the hash algorithm for add_key()
    syscall and documentation for it.

    Added entry for sm3-256 to the following tables in order to support
    TPM_ALG_SM3_256:

    * hash_algo_name
    * hash_digest_size

    Includes support for the following hash algorithms:

    * sha1
    * sha256
    * sha384
    * sha512
    * sm3-256

    Signed-off-by: Jarkko Sakkinen
    Tested-by: Colin Ian King
    Reviewed-by: James Morris
    Reviewed-by: Mimi Zohar
    Acked-by: Peter Huewe

    Jarkko Sakkinen
     

21 Oct, 2015

1 commit

  • 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
     

20 Oct, 2015

1 commit

  • This feature introduces new kernel interface:

    - /relabel-self - for setting transition labels list

    This list is used to control smack label transition mechanism.
    List is set by, and per process. Process can transit to new label only if
    label is on the list. Only process with CAP_MAC_ADMIN capability can add
    labels to this list. With this list, process can change it's label without
    CAP_MAC_ADMIN but only once. After label changing, list is unset.

    Changes in v2:
    * use list_for_each_entry instead of _rcu during label write
    * added missing description in security/Smack.txt

    Changes in v3:
    * squashed into one commit

    Changes in v4:
    * switch from global list to per-task list
    * since the per-task list is accessed only by the task itself
    there is no need to use synchronization mechanisms on it

    Changes in v5:
    * change smackfs interface of relabel-self to the one used for onlycap
    multiple labels are accepted, separated by space, which
    replace the previous list upon write

    Signed-off-by: Zbigniew Jasinski
    Signed-off-by: Rafal Krypa
    Acked-by: Casey Schaufler

    Zbigniew Jasinski
     

11 Aug, 2015

1 commit


28 Jul, 2015

2 commits

  • IPv6 appears to be (finally) coming of age with the
    influx of autonomous devices. In support of this, add
    the ability to associate a Smack label with IPv6 addresses.

    This patch also cleans up some of the conditional
    compilation associated with the introduction of
    secmark processing. It's now more obvious which bit
    of code goes with which feature.

    Signed-off-by: Casey Schaufler

    Casey Schaufler
     
  • Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded
    config for Yama to be made to explicitly stack. Just selecting the main
    Yama CONFIG will allow it to work, regardless of the major LSM. Since
    distros using Yama are already forcing it to stack, this is effectively
    a no-op change.

    Additionally add MAINTAINERS entry.

    Signed-off-by: Kees Cook
    Signed-off-by: James Morris

    Kees Cook
     

03 Jun, 2015

1 commit

  • Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to
    processes running with the configured label. But having single privileged
    label is not enough in some real use cases. On a complex system like Tizen,
    there maybe few programs that need to configure Smack policy in run-time
    and running them all with a single label is not always practical.
    This patch extends onlycap feature for multiple labels. They are configured
    in the same smackfs "onlycap" interface, separated by spaces.

    Signed-off-by: Rafal Krypa

    Rafal Krypa
     

01 Apr, 2015

1 commit


23 Jan, 2015

1 commit


19 Nov, 2014

2 commits


13 Oct, 2014

1 commit

  • This patch allows users to provide a custom template format through the
    new kernel command line parameter 'ima_template_fmt'. If the supplied
    format is not valid, IMA uses the default template descriptor.

    Changelog:
    - v3:
    - added check for 'fields' and 'num_fields' in
    template_desc_init_fields() (suggested by Mimi Zohar)

    - v2:
    - using template_desc_init_fields() to validate a format string
    (Roberto Sassu)
    - updated documentation by stating that only the chosen template
    descriptor is initialized (Roberto Sassu)

    - v1:
    - simplified code of ima_template_fmt_setup()
    (Roberto Sassu, suggested by Mimi Zohar)

    Signed-off-by: Roberto Sassu
    Signed-off-by: Mimi Zohar

    Roberto Sassu
     

17 Sep, 2014

1 commit


07 Aug, 2014

1 commit

  • Pull trivial tree changes from Jiri Kosina:
    "Summer edition of trivial tree updates"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (23 commits)
    doc: fix two typos in watchdog-api.txt
    irq-gic: remove file name from heading comment
    MAINTAINERS: Add miscdevice.h to file list for char/misc drivers.
    scsi: mvsas: mv_sas.c: Fix for possible null pointer dereference
    doc: replace "practise" with "practice" in Documentation
    befs: remove check for CONFIG_BEFS_RW
    scsi: doc: fix 'SCSI_NCR_SETUP_MASTER_PARITY'
    drivers/usb/phy/phy.c: remove a leading space
    mfd: fix comment
    cpuidle: fix comment
    doc: hpfall.c: fix missing null-terminate after strncpy call
    usb: doc: hotplug.txt code typos
    kbuild: fix comment in Makefile.modinst
    SH: add proper prompt to SH_MAGIC_PANEL_R2_VERSION
    ARM: msm: Remove MSM_SCM
    crypto: Remove MPILIB_EXTRA
    doc: CN: remove dead link, kerneltrap.org no longer works
    media: update reference, kerneltrap.org no longer works
    hexagon: update reference, kerneltrap.org no longer works
    doc: LSM: update reference, kerneltrap.org no longer works
    ...

    Linus Torvalds
     

23 Jul, 2014

2 commits


19 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
     

05 May, 2014

1 commit


12 Apr, 2014

1 commit

  • This allows to limit ptrace beyond the regular smack access rules.
    It adds a smackfs/ptrace interface that allows smack to be configured
    to require equal smack labels for PTRACE_MODE_ATTACH access.
    See the changes in Documentation/security/Smack.txt below for details.

    Signed-off-by: Lukasz Pawelczyk
    Signed-off-by: Rafal Krypa

    Lukasz Pawelczyk
     

21 Mar, 2014

1 commit


03 Jan, 2014

1 commit

  • Patch "ima: extend the measurement list to include the file signature"
    defined a new field called 'sig' and a new template called 'ima-sig'.
    This patch updates the Documentation/security/IMA-templates.txt.

    Changelog:
    - fixed formatting issues (Roberto Sassu)

    Reported-by: Roberto Sassu
    Signed-off-by: Mimi Zohar
    Signed-off-by: Roberto Sassu

    Mimi Zohar
     

26 Oct, 2013

1 commit

  • The original 'ima' template is fixed length, containing the filedata hash
    and pathname. The filedata hash is limited to 20 bytes (md5/sha1). The
    pathname is a null terminated string, limited to 255 characters. To
    overcome these limitations and to add additional file metadata, it is
    necessary to extend the current version of IMA by defining additional
    templates.

    The main reason to introduce this feature is that, each time a new
    template is defined, the functions that generate and display the
    measurement list would include the code for handling a new format and,
    thus, would significantly grow over time.

    This patch set solves this problem by separating the template management
    from the remaining IMA code. The core of this solution is the definition
    of two new data structures: a template descriptor, to determine which
    information should be included in the measurement list, and a template
    field, to generate and display data of a given type.

    To define a new template field, developers define the field identifier
    and implement two functions, init() and show(), respectively to generate
    and display measurement entries. Initially, this patch set defines the
    following template fields (support for additional data types will be
    added later):
     - 'd': the digest of the event (i.e. the digest of a measured file),
            calculated with the SHA1 or MD5 hash algorithm;
     - 'n': the name of the event (i.e. the file name), with size up to
            255 bytes;
     - 'd-ng': the digest of the event, calculated with an arbitrary hash
               algorithm (field format: [:]digest, where the digest
               prefix is shown only if the hash algorithm is not SHA1 or MD5);
     - 'n-ng': the name of the event, without size limitations.

    Defining a new template descriptor requires specifying the template format,
    a string of field identifiers separated by the '|' character. This patch
    set defines the following template descriptors:
     - "ima": its format is 'd|n';
     - "ima-ng" (default): its format is 'd-ng|n-ng'

    Further details about the new template architecture can be found in
    Documentation/security/IMA-templates.txt.

    Changelog:
    - don't defer calling ima_init_template() - Mimi
    - don't define ima_lookup_template_desc() until used - Mimi
    - squashed with documentation patch - Mimi

    Signed-off-by: Roberto Sassu
    Signed-off-by: Mimi Zohar

    Roberto Sassu
     

24 Sep, 2013

2 commits


20 Mar, 2013

1 commit

  • Rule modifications are enabled via /smack/change-rule. Format is as follows:
    "Subject Object rwaxt rwaxt"

    First two strings are subject and object labels up to 255 characters.
    Third string contains permissions to enable.
    Fourth string contains permissions to disable.

    All unmentioned permissions will be left unchanged.
    If no rule previously existed, it will be created.

    Targeted for git://git.gitorious.org/smack-next/kernel.git

    Signed-off-by: Rafal Krypa

    Rafal Krypa
     

18 Dec, 2012

1 commit


03 Oct, 2012

2 commits