28 Jun, 2016

12 commits


16 Jun, 2016

1 commit

  • avc_cache_threshold is of type unsigned int. Do not use a signed
    new_value in sscanf(page, "%u", &new_value).

    Signed-off-by: Heinrich Schuchardt
    [PM: subject prefix fix, description cleanup]
    Signed-off-by: Paul Moore

    Heinrich Schuchardt
     

09 Jun, 2016

2 commits

  • In cases where the category bitmap is sparse enough that gaps exist
    between netlbl_lsm_catmap structs, callers to netlbl_catmap_getlong()
    could find themselves prematurely ending their search through the
    category bitmap. Further, the methods used to calculate the 'idx'
    and 'off' values were incorrect for bitmaps this large. This patch
    changes the netlbl_catmap_getlong() behavior so that it always skips
    over gaps and calculates the index and offset values correctly.

    Signed-off-by: Paul Moore

    Paul Moore
     
  • The existing ebitmap_netlbl_import() code didn't correctly handle the
    case where the ebitmap_node was not aligned/sized to a power of two,
    this patch fixes this (on x86_64 ebitmap_node contains six bitmaps
    making a range of 0..383).

    Signed-off-by: Paul Moore

    Paul Moore
     

07 Jun, 2016

2 commits


01 Jun, 2016

1 commit

  • The current bounds checking of both source and target types
    requires allowing any domain that has access to the child
    domain to also have the same permissions to the parent, which
    is undesirable. Drop the target bounds checking.

    KaiGai Kohei originally removed all use of target bounds in
    commit 7d52a155e38d ("selinux: remove dead code in
    type_attribute_bounds_av()") but this was reverted in
    commit 2ae3ba39389b ("selinux: libsepol: remove dead code in
    check_avtab_hierarchy_callback()") because it would have
    required explicitly allowing the parent any permissions
    to the child that the child is allowed to itself.

    This change in contrast retains the logic for the case where both
    source and target types are bounded, thereby allowing access
    if the parent of the source is allowed the corresponding
    permissions to the parent of the target. Further, this change
    reworks the logic such that we only perform a single computation
    for each case and there is no ambiguity as to how to resolve
    a bounds violation.

    Under the new logic, if the source type and target types are both
    bounded, then the parent of the source type must be allowed the same
    permissions to the parent of the target type. If only the source
    type is bounded, then the parent of the source type must be allowed
    the same permissions to the target type.

    Examples of the new logic and comparisons with the old logic:
    1. If we have:
    typebounds A B;
    then:
    allow B self:process ;
    will satisfy the bounds constraint iff:
    allow A self:process ;
    is also allowed in policy.

    Under the old logic, the allow rule on B satisfies the
    bounds constraint if any of the following three are allowed:
    allow A B:process ; or
    allow B A:process ; or
    allow A self:process ;
    However, either of the first two ultimately require the third to
    satisfy the bounds constraint under the old logic, and therefore
    this degenerates to the same result (but is more efficient - we only
    need to perform one compute_av call).

    2. If we have:
    typebounds A B;
    typebounds A_exec B_exec;
    then:
    allow B B_exec:file ;
    will satisfy the bounds constraint iff:
    allow A A_exec:file ;
    is also allowed in policy.

    This is essentially the same as #1; it is merely included as
    an example of dealing with object types related to a bounded domain
    in a manner that satisfies the bounds relationship. Note that
    this approach is preferable to leaving B_exec unbounded and having:
    allow A B_exec:file ;
    in policy because that would allow B's entrypoints to be used to
    enter A. Similarly for _tmp or other related types.

    3. If we have:
    typebounds A B;
    and an unbounded type T, then:
    allow B T:file ;
    will satisfy the bounds constraint iff:
    allow A T:file ;
    is allowed in policy.

    The old logic would have been identical for this example.

    4. If we have:
    typebounds A B;
    and an unbounded domain D, then:
    allow D B:unix_stream_socket ;
    is not subject to any bounds constraints under the new logic
    because D is not bounded. This is desirable so that we can
    allow a domain to e.g. connectto a child domain without having
    to allow it to do the same to its parent.

    The old logic would have required:
    allow D A:unix_stream_socket ;
    to also be allowed in policy.

    Signed-off-by: Stephen Smalley
    [PM: re-wrapped description to appease checkpatch.pl]
    Signed-off-by: Paul Moore

    Stephen Smalley
     

17 May, 2016

1 commit

  • Instead of being enabled by default when SECURITY_LOADPIN is selected,
    provide an additional (default off) config to determine the boot time
    behavior. As before, the "loadpin.enabled=0/1" kernel parameter remains
    available.

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

    Kees Cook
     

06 May, 2016

2 commits


05 May, 2016

3 commits

  • Access reporting often happens from atomic contexes. Avoid
    lockups when allocating memory for command lines.

    Fixes: 8a56038c2ae ("Yama: consolidate error reporting")
    Signed-off-by: Sasha Levin

    Sasha Levin
     
  • Drop accidentally repeated word in comment.

    Signed-off-by: Mickaël Salaün
    Cc: Kees Cook
    Cc: Andy Lutomirski
    Cc: Will Drewry

    Mickaël Salaün
     
  • 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
     

01 May, 2016

3 commits

  • Commit 3034a14 "ima: pass 'opened' flag to identify newly created files"
    stopped identifying empty files as new files. However new empty files
    can be created using the mknodat syscall. On systems with IMA-appraisal
    enabled, these empty files are not labeled with security.ima extended
    attributes properly, preventing them from subsequently being opened in
    order to write the file data contents. This patch defines a new hook
    named ima_post_path_mknod() to mark these empty files, created using
    mknodat, as new in order to allow the file data contents to be written.

    In addition, files with security.ima xattrs containing a file signature
    are considered "immutable" and can not be modified. The file contents
    need to be written, before signing the file. This patch relaxes this
    requirement for new files, allowing the file signature to be written
    before the file contents.

    Changelog:
    - defer identifying files with signatures stored as security.ima
    (based on Dmitry Rozhkov's comments)
    - removing tests (eg. dentry, dentry->d_inode, inode->i_size == 0)
    (based on Al's review)

    Signed-off-by: Mimi Zohar
    Cc: Al Viro <
    Tested-by: Dmitry Rozhkov

    Mimi Zohar
     
  • Changing file metadata (eg. uid, guid) could result in having to
    re-appraise a file's integrity, but does not change the "new file"
    status nor the security.ima xattr. The IMA_PERMIT_DIRECTIO and
    IMA_DIGSIG_REQUIRED flags are policy rule specific. This patch
    only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags.

    With this patch, changing the file timestamp will not remove the
    file signature on new files.

    Reported-by: Dmitry Rozhkov
    Signed-off-by: Mimi Zohar
    Tested-by: Dmitry Rozhkov

    Mimi Zohar
     
  • This patch is based on top of the "vfs: support for a common kernel file
    loader" patch set. In general when the kernel is reading a file into
    memory it does not want anything else writing to it.

    The kernel currently only forbids write access to a file being executed.
    This patch extends this locking to files being read by the kernel.

    Changelog:
    - moved function to kernel_read_file() - Mimi
    - updated patch description - Mimi

    Signed-off-by: Dmitry Kasatkin
    Cc: Al Viro
    Signed-off-by: Mimi Zohar
    Reviewed-by: Luis R. Rodriguez
    Acked-by: Kees Cook

    Dmitry Kasatkin
     

27 Apr, 2016

3 commits

  • When I was fixing up const recommendations from checkpatch.pl, I went
    overboard. This fixes the warning (during a W=1 build):

    include/linux/fs.h:2627:74: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
    static inline const char * const kernel_read_file_id_str(enum kernel_read_file_id id)

    Reported-by: Andy Shevchenko
    Signed-off-by: Kees Cook
    Signed-off-by: James Morris

    Kees Cook
     
  • The execstack check was only being applied on the main
    process stack. Thread stacks allocated via mmap were
    only subject to the execmem permission check. Augment
    the check to apply to the current thread stack as well.
    Note that this does NOT prevent making a different thread's
    stack executable.

    Suggested-by: Nick Kralevich
    Acked-by: Nick Kralevich
    Signed-off-by: Stephen Smalley
    Signed-off-by: Paul Moore

    Stephen Smalley
     
  • Distinguish capability checks against a target associated
    with the init user namespace versus capability checks against
    a target associated with a non-init user namespace by defining
    and using separate security classes for the latter.

    This is needed to support e.g. Chrome usage of user namespaces
    for the Chrome sandbox without needing to allow Chrome to also
    exercise capabilities on targets in the init user namespace.

    Suggested-by: Dan Walsh
    Signed-off-by: Stephen Smalley
    Signed-off-by: Paul Moore

    Stephen Smalley
     

21 Apr, 2016

6 commits

  • 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
     
  • A string representation of the kernel_read_file_id enumeration is
    needed for displaying messages (eg. pr_info, auditing) that can be
    used by multiple LSMs and the integrity subsystem. To simplify
    keeping the list of strings up to date with the enumeration, this
    patch defines two new preprocessing macros named __fid_enumify and
    __fid_stringify to create the enumeration and an array of strings.
    kernel_read_file_id_str() returns a string based on the enumeration.

    Signed-off-by: Mimi Zohar
    [kees: removed removal of my old version, constified pointer values]
    Signed-off-by: Kees Cook
    Signed-off-by: James Morris

    Mimi Zohar
     
  • Use a common error reporting function for Yama violation reports, and give
    more detail into the process command lines.

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

    Kees Cook
     
  • Allocate a NULL-terminated file path with special characters escaped,
    safe for logging.

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

    Kees Cook
     
  • Provide an escaped (but readable: no inter-argument NULLs) commandline
    safe for logging.

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

    Kees Cook
     
  • Handle allocating and escaping a string safe for logging.

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

    Kees Cook
     

20 Apr, 2016

3 commits


14 Apr, 2016

1 commit

  • security_get_bool_value(int bool) argument "bool" conflicts with
    in-kernel macros such as BUILD_BUG(). This patch changes this to
    index which isn't a type.

    Cc: Paul Moore
    Cc: Stephen Smalley
    Cc: Eric Paris
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Rasmus Villemoes
    Cc: Andrew Perepechko
    Cc: Jeff Vander Stoep
    Cc: selinux@tycho.nsa.gov
    Cc: Eric Paris
    Cc: Paul Moore
    Cc: David Howells
    Signed-off-by: Prarit Bhargava
    Acked-by: David Howells
    [PM: wrapped description for checkpatch.pl, use "selinux:..." as subj]
    Signed-off-by: Paul Moore

    Prarit Bhargava