1. 06 Jun, 2016 1 commit
  2. 31 May, 2016 1 commit
    • Stephen Smalley's avatar
      selinux: Only apply bounds checking to source types · 7ea59202
      Stephen Smalley authored
      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 7d52a155 ("selinux: remove dead code in
      type_attribute_bounds_av()") but this was reverted in
      commit 2ae3ba39 ("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 <permissions>;
      will satisfy the bounds constraint iff:
      	allow A self:process <permissions>;
      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 <permissions>; or
      	allow B A:process <permissions>; or
      	allow A self:process <permissions>;
      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 <permissions>;
      will satisfy the bounds constraint iff:
      	allow A A_exec:file <permissions>;
      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 <permissions>;
      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 <permissions>;
      will satisfy the bounds constraint iff:
      	allow A T:file <permissions>;
      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 <permissions>;
      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 <permissions>;
      to also be allowed in policy.
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: re-wrapped description to appease checkpatch.pl]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      7ea59202
  3. 17 May, 2016 1 commit
  4. 05 May, 2016 2 commits
  5. 04 May, 2016 3 commits
    • Sasha Levin's avatar
      Yama: use atomic allocations when reporting · 74f430cd
      Sasha Levin authored
      Access reporting often happens from atomic contexes. Avoid
      lockups when allocating memory for command lines.
      
      Fixes: 8a56038c ("Yama: consolidate error reporting")
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      74f430cd
    • Mickaël Salaün's avatar
      seccomp: Fix comment typo · 470bf1f2
      Mickaël Salaün authored
      Drop accidentally repeated word in comment.
      Signed-off-by: default avatarMickaël Salaün <mic@digikod.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Will Drewry <wad@chromium.org>
      470bf1f2
    • David Howells's avatar
      Merge branch 'keys-trust' into keys-next · d55201ce
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      d55201ce
  6. 01 May, 2016 3 commits
    • Mimi Zohar's avatar
      ima: add support for creating files using the mknodat syscall · 05d1a717
      Mimi Zohar authored
      Commit 3034a146 "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: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Al Viro <<viro@zeniv.linux.org.uk>
      Tested-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      05d1a717
    • Mimi Zohar's avatar
      ima: fix ima_inode_post_setattr · 42a4c603
      Mimi Zohar authored
      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: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Tested-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      42a4c603
    • Dmitry Kasatkin's avatar
      vfs: forbid write access when reading a file into memory · 39d637af
      Dmitry Kasatkin authored
      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: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      39d637af
  7. 27 Apr, 2016 1 commit
  8. 26 Apr, 2016 2 commits
  9. 21 Apr, 2016 6 commits
  10. 19 Apr, 2016 3 commits
  11. 14 Apr, 2016 1 commit
    • Prarit Bhargava's avatar
      selinux: Change bool variable name to index. · 0fd71a62
      Prarit Bhargava authored
      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 <paul@paul-moore.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Andrew Perepechko <anserper@ya.ru>
      Cc: Jeff Vander Stoep <jeffv@google.com>
      Cc: selinux@tycho.nsa.gov
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Paul Moore <pmoore@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      [PM: wrapped description for checkpatch.pl, use "selinux:..." as subj]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      0fd71a62
  12. 12 Apr, 2016 6 commits
  13. 11 Apr, 2016 10 commits
    • David Howells's avatar
      IMA: Use the the system trusted keyrings instead of .ima_mok · 56104cf2
      David Howells authored
      Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
      that, when enabled, allows keys to be added to the IMA keyrings by
      userspace - with the restriction that each must be signed by a key in the
      system trusted keyrings.
      
      EPERM will be returned if this option is disabled, ENOKEY will be returned if
      no authoritative key can be found and EKEYREJECTED will be returned if the
      signature doesn't match.  Other errors such as ENOPKG may also be returned.
      
      If this new option is enabled, the builtin system keyring is searched, as is
      the secondary system keyring if that is also enabled.  Intermediate keys
      between the builtin system keyring and the key being added can be added to
      the secondary keyring (which replaces .ima_mok) to form a trust chain -
      provided they are also validly signed by a key in one of the trusted keyrings.
      
      The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
      own config option (IMA_BLACKLIST_KEYRING).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      56104cf2
    • David Howells's avatar
      certs: Add a secondary system keyring that can be added to dynamically · d3bfe841
      David Howells authored
      Add a secondary system keyring that can be added to by root whilst the
      system is running - provided the key being added is vouched for by a key
      built into the kernel or already added to the secondary keyring.
      
      Rename .system_keyring to .builtin_trusted_keys to distinguish it more
      obviously from the new keyring (called .secondary_trusted_keys).
      
      The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.
      
      If the secondary keyring is enabled, a link is created from that to
      .builtin_trusted_keys so that the the latter will automatically be searched
      too if the secondary keyring is searched.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d3bfe841
    • David Howells's avatar
      KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED · 77f68bac
      David Howells authored
      Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
      meaningful.  Also we can drop the trusted flag from the preparse structure.
      
      Given this, we no longer need to pass the key flags through to
      restrict_link().
      
      Further, we can now get rid of keyring_restrict_trusted_only() also.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      77f68bac
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      David Howells authored
      Move the point at which a key is determined to be trustworthy to
      __key_link() so that we use the contents of the keyring being linked in to
      to determine whether the key being linked in is trusted or not.
      
      What is 'trusted' then becomes a matter of what's in the keyring.
      
      Currently, the test is done when the key is parsed, but given that at that
      point we can only sensibly refer to the contents of the system trusted
      keyring, we can only use that as the basis for working out the
      trustworthiness of a new key.
      
      With this change, a trusted keyring is a set of keys that once the
      trusted-only flag is set cannot be added to except by verification through
      one of the contained keys.
      
      Further, adding a key into a trusted keyring, whilst it might grant
      trustworthiness in the context of that keyring, does not automatically
      grant trustworthiness in the context of a second keyring to which it could
      be secondarily linked.
      
      To accomplish this, the authentication data associated with the key source
      must now be retained.  For an X.509 cert, this means the contents of the
      AuthorityKeyIdentifier and the signature data.
      
      
      If system keyrings are disabled then restrict_link_by_builtin_trusted()
      resolves to restrict_link_reject().  The integrity digital signature code
      still works correctly with this as it was previously using
      KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
      is no system keyring against which trust can be determined.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      a511e1af
    • David Howells's avatar
      KEYS: Make the system trusted keyring depend on the asymmetric key type · 99716b7c
      David Howells authored
      Make the system trusted keyring depend on the asymmetric key type as
      there's not a lot of point having it if you can't then load asymmetric keys
      onto it.
      
      This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
      the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
      'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.
      
      Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
      work as the Kconfig interpreter then wrongly complains about dependency
      loops.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      99716b7c
    • David Howells's avatar
      X.509: Move the trust validation code out to its own file · cfb664ff
      David Howells authored
      Move the X.509 trust validation code out to its own file so that it can be
      generalised.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cfb664ff
    • David Howells's avatar
      X.509: Use verify_signature() if we have a struct key * to use · 5f7f5c81
      David Howells authored
      We should call verify_signature() rather than directly calling
      public_key_verify_signature() if we have a struct key to use as we
      shouldn't be poking around in the private data of the key struct as that's
      subtype dependent.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5f7f5c81
    • David Howells's avatar
      KEYS: Generalise x509_request_asymmetric_key() · 9eb02989
      David Howells authored
      Generalise x509_request_asymmetric_key().  It doesn't really have any
      dependencies on X.509 features as it uses generalised IDs and the
      public_key structs that contain data extracted from X.509.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      9eb02989
    • David Howells's avatar
      KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c · 983023f2
      David Howells authored
      Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
      generalised.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      983023f2
    • David Howells's avatar
      KEYS: Add a facility to restrict new links into a keyring · 5ac7eace
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      5ac7eace