1. 05 10月, 2019 2 次提交
  2. 30 8月, 2019 2 次提交
    • G
      ima: ima_api: Use struct_size() in kzalloc() · 2a7f0e53
      Gustavo A. R. Silva 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct ima_template_entry {
      	...
              struct ima_field_data template_data[0]; /* template related data */
      };
      
      instance = kzalloc(sizeof(struct ima_template_entry) + count * sizeof(struct ima_field_data), GFP_NOFS);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = kzalloc(struct_size(instance, entry, count), GFP_NOFS);
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      2a7f0e53
    • G
      ima: use struct_size() in kzalloc() · fa5b5717
      Gustavo A. R. Silva 提交于
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
         int stuff;
         struct boo entry[];
      };
      
      instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
      
      This code was detected with the help of Coccinelle.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      fa5b5717
  3. 29 8月, 2019 1 次提交
  4. 20 8月, 2019 2 次提交
    • M
      kexec: Allow kexec_file() with appropriate IMA policy when locked down · 29d3c1c8
      Matthew Garrett 提交于
      Systems in lockdown mode should block the kexec of untrusted kernels.
      For x86 and ARM we can ensure that a kernel is trustworthy by validating
      a PE signature, but this isn't possible on other architectures. On those
      platforms we can use IMA digital signatures instead. Add a function to
      determine whether IMA has or will verify signatures for a given event type,
      and if so permit kexec_file() even if the kernel is otherwise locked down.
      This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set
      in order to prevent an attacker from loading additional keys at runtime.
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Acked-by: NMimi Zohar <zohar@linux.ibm.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: linux-integrity@vger.kernel.org
      Signed-off-by: NJames Morris <jmorris@namei.org>
      29d3c1c8
    • J
      kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE · 99d5cadf
      Jiri Bohac 提交于
      This is a preparatory patch for kexec_file_load() lockdown.  A locked down
      kernel needs to prevent unsigned kernel images from being loaded with
      kexec_file_load().  Currently, the only way to force the signature
      verification is compiling with KEXEC_VERIFY_SIG.  This prevents loading
      usigned images even when the kernel is not locked down at runtime.
      
      This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
      Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
      turns on the signature verification but allows unsigned images to be
      loaded.  KEXEC_SIG_FORCE disallows images without a valid signature.
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      cc: kexec@lists.infradead.org
      Signed-off-by: NJames Morris <jmorris@namei.org>
      99d5cadf
  5. 06 8月, 2019 9 次提交
  6. 01 8月, 2019 1 次提交
    • M
      ima: initialize the "template" field with the default template · b36f281f
      Mimi Zohar 提交于
      IMA policy rules are walked sequentially.  Depending on the ordering of
      the policy rules, the "template" field might be defined in one rule, but
      will be replaced by subsequent, applicable rules, even if the rule does
      not explicitly define the "template" field.
      
      This patch initializes the "template" once and only replaces the
      "template", when explicitly defined.
      
      Fixes: 19453ce0 ("IMA: support for per policy rule template formats")
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      b36f281f
  7. 11 7月, 2019 1 次提交
  8. 01 7月, 2019 3 次提交
    • T
      integrity: Introduce struct evm_xattr · 650b29db
      Thiago Jung Bauermann 提交于
      Even though struct evm_ima_xattr_data includes a fixed-size array to hold a
      SHA1 digest, most of the code ignores the array and uses the struct to mean
      "type indicator followed by data of unspecified size" and tracks the real
      size of what the struct represents in a separate length variable.
      
      The only exception to that is the EVM code, which correctly uses the
      definition of struct evm_ima_xattr_data.
      
      So make this explicit in the code by removing the length specification from
      the array in struct evm_ima_xattr_data. Also, change the name of the
      element from digest to data since in most places the array doesn't hold a
      digest.
      
      A separate struct evm_xattr is introduced, with the original definition of
      evm_ima_xattr_data to be used in the places that actually expect that
      definition, specifically the EVM HMAC code.
      Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      650b29db
    • T
      ima: Update MAX_TEMPLATE_NAME_LEN to fit largest reasonable definition · 337619eb
      Thiago Jung Bauermann 提交于
      MAX_TEMPLATE_NAME_LEN is used when restoring measurements carried over from
      a kexec. It should be set to the length of a template containing all fields
      except for 'd' and 'n', which don't need to be accounted for since they
      shouldn't be defined in the same template description as 'd-ng' and 'n-ng'.
      
      That length is greater than the current 15, so update using a sizeof() to
      show where the number comes from and also can be visually shown to be
      correct. The sizeof() is calculated at compile time.
      Signed-off-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      337619eb
    • P
      IMA: Define a new template field buf · 86b4da8c
      Prakhar Srivastava 提交于
      A buffer(kexec boot command line arguments) measured into IMA
      measuremnt list cannot be appraised, without already being
      aware of the buffer contents. Since hashes are non-reversible,
      raw buffer is needed for validation or regenerating hash for
      appraisal/attestation.
      
      Add support to store/read the buffer contents in HEX.
      The kexec cmdline hash is stored in the "d-ng" field of the
      template data.  It can be verified using
      sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements |
        grep  kexec-cmdline | cut -d' ' -f 6 | xxd -r -p | sha256sum
      
      - Add two new fields to ima_event_data to hold the buf and
      buf_len
      - Add a new template field 'buf' to be used to store/read
      the buffer data.
      - Updated process_buffer_meaurement to add the buffer to
      ima_event_data. process_buffer_measurement added in
      "Define a new IMA hook to measure the boot command line
       arguments"
      - Add a new template policy name ima-buf to represent
      'd-ng|n-ng|buf'
      Signed-off-by: NPrakhar Srivastava <prsriva02@gmail.com>
      Reviewed-by: NRoberto Sassu <roberto.sassu@huawei.com>
      Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      86b4da8c
  9. 28 6月, 2019 1 次提交
    • D
      keys: Replace uid/gid/perm permissions checking with an ACL · 2e12256b
      David Howells 提交于
      Replace the uid/gid/perm permissions checking on a key with an ACL to allow
      the SETATTR and SEARCH permissions to be split.  This will also allow a
      greater range of subjects to represented.
      
      ============
      WHY DO THIS?
      ============
      
      The problem is that SETATTR and SEARCH cover a slew of actions, not all of
      which should be grouped together.
      
      For SETATTR, this includes actions that are about controlling access to a
      key:
      
       (1) Changing a key's ownership.
      
       (2) Changing a key's security information.
      
       (3) Setting a keyring's restriction.
      
      And actions that are about managing a key's lifetime:
      
       (4) Setting an expiry time.
      
       (5) Revoking a key.
      
      and (proposed) managing a key as part of a cache:
      
       (6) Invalidating a key.
      
      Managing a key's lifetime doesn't really have anything to do with
      controlling access to that key.
      
      Expiry time is awkward since it's more about the lifetime of the content
      and so, in some ways goes better with WRITE permission.  It can, however,
      be set unconditionally by a process with an appropriate authorisation token
      for instantiating a key, and can also be set by the key type driver when a
      key is instantiated, so lumping it with the access-controlling actions is
      probably okay.
      
      As for SEARCH permission, that currently covers:
      
       (1) Finding keys in a keyring tree during a search.
      
       (2) Permitting keyrings to be joined.
      
       (3) Invalidation.
      
      But these don't really belong together either, since these actions really
      need to be controlled separately.
      
      Finally, there are number of special cases to do with granting the
      administrator special rights to invalidate or clear keys that I would like
      to handle with the ACL rather than key flags and special checks.
      
      
      ===============
      WHAT IS CHANGED
      ===============
      
      The SETATTR permission is split to create two new permissions:
      
       (1) SET_SECURITY - which allows the key's owner, group and ACL to be
           changed and a restriction to be placed on a keyring.
      
       (2) REVOKE - which allows a key to be revoked.
      
      The SEARCH permission is split to create:
      
       (1) SEARCH - which allows a keyring to be search and a key to be found.
      
       (2) JOIN - which allows a keyring to be joined as a session keyring.
      
       (3) INVAL - which allows a key to be invalidated.
      
      The WRITE permission is also split to create:
      
       (1) WRITE - which allows a key's content to be altered and links to be
           added, removed and replaced in a keyring.
      
       (2) CLEAR - which allows a keyring to be cleared completely.  This is
           split out to make it possible to give just this to an administrator.
      
       (3) REVOKE - see above.
      
      
      Keys acquire ACLs which consist of a series of ACEs, and all that apply are
      unioned together.  An ACE specifies a subject, such as:
      
       (*) Possessor - permitted to anyone who 'possesses' a key
       (*) Owner - permitted to the key owner
       (*) Group - permitted to the key group
       (*) Everyone - permitted to everyone
      
      Note that 'Other' has been replaced with 'Everyone' on the assumption that
      you wouldn't grant a permit to 'Other' that you wouldn't also grant to
      everyone else.
      
      Further subjects may be made available by later patches.
      
      The ACE also specifies a permissions mask.  The set of permissions is now:
      
      	VIEW		Can view the key metadata
      	READ		Can read the key content
      	WRITE		Can update/modify the key content
      	SEARCH		Can find the key by searching/requesting
      	LINK		Can make a link to the key
      	SET_SECURITY	Can change owner, ACL, expiry
      	INVAL		Can invalidate
      	REVOKE		Can revoke
      	JOIN		Can join this keyring
      	CLEAR		Can clear this keyring
      
      
      The KEYCTL_SETPERM function is then deprecated.
      
      The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
      or if the caller has a valid instantiation auth token.
      
      The KEYCTL_INVALIDATE function then requires INVAL.
      
      The KEYCTL_REVOKE function then requires REVOKE.
      
      The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
      existing keyring.
      
      The JOIN permission is enabled by default for session keyrings and manually
      created keyrings only.
      
      
      ======================
      BACKWARD COMPATIBILITY
      ======================
      
      To maintain backward compatibility, KEYCTL_SETPERM will translate the
      permissions mask it is given into a new ACL for a key - unless
      KEYCTL_SET_ACL has been called on that key, in which case an error will be
      returned.
      
      It will convert possessor, owner, group and other permissions into separate
      ACEs, if each portion of the mask is non-zero.
      
      SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY.  WRITE
      permission turns on WRITE, REVOKE and, if a keyring, CLEAR.  JOIN is turned
      on if a keyring is being altered.
      
      The KEYCTL_DESCRIBE function translates the ACL back into a permissions
      mask to return depending on possessor, owner, group and everyone ACEs.
      
      It will make the following mappings:
      
       (1) INVAL, JOIN -> SEARCH
      
       (2) SET_SECURITY -> SETATTR
      
       (3) REVOKE -> WRITE if SETATTR isn't already set
      
       (4) CLEAR -> WRITE
      
      Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
      the value set with KEYCTL_SETATTR.
      
      
      =======
      TESTING
      =======
      
      This passes the keyutils testsuite for all but a couple of tests:
      
       (1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
           returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
           if the type doesn't have ->read().  You still can't actually read the
           key.
      
       (2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
           work as Other has been replaced with Everyone in the ACL.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2e12256b
  10. 27 6月, 2019 1 次提交
  11. 24 6月, 2019 1 次提交
  12. 20 6月, 2019 1 次提交
  13. 18 6月, 2019 1 次提交
  14. 14 6月, 2019 4 次提交
  15. 05 6月, 2019 2 次提交
  16. 31 5月, 2019 1 次提交
  17. 30 5月, 2019 2 次提交
  18. 21 5月, 2019 1 次提交
  19. 20 5月, 2019 1 次提交
  20. 26 4月, 2019 1 次提交
  21. 25 4月, 2019 1 次提交
    • E
      crypto: shash - remove shash_desc::flags · 877b5691
      Eric Biggers 提交于
      The flags field in 'struct shash_desc' never actually does anything.
      The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
      However, no shash algorithm ever sleeps, making this flag a no-op.
      
      With this being the case, inevitably some users who can't sleep wrongly
      pass MAY_SLEEP.  These would all need to be fixed if any shash algorithm
      actually started sleeping.  For example, the shash_ahash_*() functions,
      which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
      from the ahash API to the shash API.  However, the shash functions are
      called under kmap_atomic(), so actually they're assumed to never sleep.
      
      Even if it turns out that some users do need preemption points while
      hashing large buffers, we could easily provide a helper function
      crypto_shash_update_large() which divides the data into smaller chunks
      and calls crypto_shash_update() and cond_resched() for each chunk.  It's
      not necessary to have a flag in 'struct shash_desc', nor is it necessary
      to make individual shash algorithms aware of this at all.
      
      Therefore, remove shash_desc::flags, and document that the
      crypto_shash_*() functions can be called from any context.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      877b5691
  22. 18 4月, 2019 1 次提交