1. 05 2月, 2019 3 次提交
  2. 29 12月, 2018 1 次提交
  3. 21 12月, 2018 2 次提交
  4. 18 12月, 2018 2 次提交
  5. 13 12月, 2018 10 次提交
  6. 11 12月, 2018 5 次提交
    • M
      ima: don't measure/appraise files on efivarfs · 060190fb
      Mimi Zohar 提交于
      Update the builtin IMA policies specified on the boot command line
      (eg. ima_policy="tcb|appraise_tcb") to permit accessing efivar files.
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      060190fb
    • E
      x86/ima: define arch_get_ima_policy() for x86 · d958083a
      Eric Richter 提交于
      On x86, there are two methods of verifying a kexec'ed kernel image
      signature being loaded via the kexec_file_load syscall - an architecture
      specific implementaton or a IMA KEXEC_KERNEL_CHECK appraisal rule. Neither
      of these methods verify the kexec'ed kernel image signature being loaded
      via the kexec_load syscall.
      
      Secure boot enabled systems require kexec images to be signed. Therefore,
      this patch loads an IMA KEXEC_KERNEL_CHECK policy rule on secure boot
      enabled systems not configured with CONFIG_KEXEC_VERIFY_SIG enabled.
      
      When IMA_APPRAISE_BOOTPARAM is configured, different IMA appraise modes
      (eg. fix, log) can be specified on the boot command line, allowing unsigned
      or invalidly signed kernel images to be kexec'ed. This patch permits
      enabling IMA_APPRAISE_BOOTPARAM or IMA_ARCH_POLICY, but not both.
      Signed-off-by: NEric Richter <erichte@linux.ibm.com>
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Dave Young <dyoung@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      d958083a
    • N
      ima: add support for arch specific policies · 61917062
      Nayna Jain 提交于
      Builtin IMA policies can be enabled on the boot command line, and replaced
      with a custom policy, normally during early boot in the initramfs. Build
      time IMA policy rules were recently added. These rules are automatically
      enabled on boot and persist after loading a custom policy.
      
      There is a need for yet another type of policy, an architecture specific
      policy, which is derived at runtime during kernel boot, based on the
      runtime secure boot flags.  Like the build time policy rules, these rules
      persist after loading a custom policy.
      
      This patch adds support for loading an architecture specific IMA policy.
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      Co-Developed-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      61917062
    • N
      ima: refactor ima_init_policy() · c52657d9
      Nayna Jain 提交于
      This patch removes the code duplication in ima_init_policy() by defining
      a new function named add_rules(). The new function adds the rules to the
      initial IMA policy, the custom policy or both based on the policy mask
      (IMA_DEFAULT_POLICY, IMA_CUSTOM_POLICY).
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      c52657d9
    • N
      ima: prevent kexec_load syscall based on runtime secureboot flag · b5ca1173
      Nayna Jain 提交于
      When CONFIG_KEXEC_VERIFY_SIG is enabled, the kexec_file_load syscall
      requires the kexec'd kernel image to be signed. Distros are concerned
      about totally disabling the kexec_load syscall. As a compromise, the
      kexec_load syscall will only be disabled when CONFIG_KEXEC_VERIFY_SIG
      is configured and the system is booted with secureboot enabled.
      
      This patch disables the kexec_load syscall only for systems booted with
      secureboot enabled.
      
      [zohar@linux.ibm.com: add missing mesage on kexec_load failure]
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Dave Young <dyoung@redhat.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      b5ca1173
  7. 27 11月, 2018 1 次提交
  8. 20 11月, 2018 1 次提交
  9. 14 11月, 2018 1 次提交
    • M
      integrity: support new struct public_key_signature encoding field · fd35f192
      Mimi Zohar 提交于
      On systems with IMA-appraisal enabled with a policy requiring file
      signatures, the "good" signature values are stored on the filesystem as
      extended attributes (security.ima).  Signature verification failure
      would normally be limited to just a particular file (eg. executable),
      but during boot signature verification failure could result in a system
      hang.
      
      Defining and requiring a new public_key_signature field requires all
      callers of asymmetric signature verification to be updated to reflect
      the change.  This patch updates the integrity asymmetric_verify()
      caller.
      
      Fixes: 82f94f24 ("KEYS: Provide software public key query function [ver #2]")
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Acked-by: NDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: NJames Morris <james.morris@microsoft.com>
      fd35f192
  10. 13 11月, 2018 2 次提交
  11. 11 10月, 2018 7 次提交
  12. 28 7月, 2018 2 次提交
  13. 23 7月, 2018 1 次提交
  14. 18 7月, 2018 2 次提交
    • M
      integrity: prevent deadlock during digsig verification. · 6eb864c1
      Mikhail Kurinnoi 提交于
      This patch aimed to prevent deadlock during digsig verification.The point
      of issue - user space utility modprobe and/or it's dependencies (ld-*.so,
      libz.so.*, libc-*.so and /lib/modules/ files) that could be used for
      kernel modules load during digsig verification and could be signed by
      digsig in the same time.
      
      First at all, look at crypto_alloc_tfm() work algorithm:
      crypto_alloc_tfm() will first attempt to locate an already loaded
      algorithm. If that fails and the kernel supports dynamically loadable
      modules, it will then attempt to load a module of the same name or alias.
      If that fails it will send a query to any loaded crypto manager to
      construct an algorithm on the fly.
      
      We have situation, when public_key_verify_signature() in case of RSA
      algorithm use alg_name to store internal information in order to construct
      an algorithm on the fly, but crypto_larval_lookup() will try to use
      alg_name in order to load kernel module with same name.
      
      1) we can't do anything with crypto module work, since it designed to work
      exactly in this way;
      2) we can't globally filter module requests for modprobe, since it
      designed to work with any requests.
      
      In this patch, I propose add an exception for "crypto-pkcs1pad(rsa,*)"
      module requests only in case of enabled integrity asymmetric keys support.
      Since we don't have any real "crypto-pkcs1pad(rsa,*)" kernel modules for
      sure, we are safe to fail such module request from crypto_larval_lookup().
      In this way we prevent modprobe execution during digsig verification and
      avoid possible deadlock if modprobe and/or it's dependencies also signed
      with digsig.
      
      Requested "crypto-pkcs1pad(rsa,*)" kernel module name formed by:
      1) "pkcs1pad(rsa,%s)" in public_key_verify_signature();
      2) "crypto-%s" / "crypto-%s-all" in crypto_larval_lookup().
      "crypto-pkcs1pad(rsa," part of request is a constant and unique and could
      be used as filter.
      Signed-off-by: NMikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      
       include/linux/integrity.h              | 13 +++++++++++++
       security/integrity/digsig_asymmetric.c | 23 +++++++++++++++++++++++
       security/security.c                    |  7 ++++++-
       3 files changed, 42 insertions(+), 1 deletion(-)
      6eb864c1
    • M
      evm: Allow non-SHA1 digital signatures · 5feeb611
      Matthew Garrett 提交于
      SHA1 is reasonable in HMAC constructs, but it's desirable to be able to
      use stronger hashes in digital signatures. Modify the EVM crypto code so
      the hash type is imported from the digital signature and passed down to
      the hash calculation code, and return the digest size to higher layers
      for validation.
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      5feeb611