1. 05 Dec, 2018 35 commits
  2. 01 Dec, 2018 5 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.85 · 5ff1ad55
      Greg Kroah-Hartman authored
      5ff1ad55
    • Mimi Zohar's avatar
      ima: re-initialize iint->atomic_flags · d467320f
      Mimi Zohar authored
      commit e2598077 upstream.
      
      Intermittently security.ima is not being written for new files.  This
      patch re-initializes the new slab iint->atomic_flags field before
      freeing it.
      
      Fixes: commit 0d73a552 ("ima: re-introduce own integrity cache lock")
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d467320f
    • Dmitry Kasatkin's avatar
      ima: re-introduce own integrity cache lock · 281c07f3
      Dmitry Kasatkin authored
      commit 0d73a552 upstream.
      
      Before IMA appraisal was introduced, IMA was using own integrity cache
      lock along with i_mutex. process_measurement and ima_file_free took
      the iint->mutex first and then the i_mutex, while setxattr, chmod and
      chown took the locks in reverse order. To resolve the potential deadlock,
      i_mutex was moved to protect entire IMA functionality and the redundant
      iint->mutex was eliminated.
      
      Solution was based on the assumption that filesystem code does not take
      i_mutex further. But when file is opened with O_DIRECT flag, direct-io
      implementation takes i_mutex and produces deadlock. Furthermore, certain
      other filesystem operations, such as llseek, also take i_mutex.
      
      More recently some filesystems have replaced their filesystem specific
      lock with the global i_rwsem to read a file.  As a result, when IMA
      attempts to calculate the file hash, reading the file attempts to take
      the i_rwsem again.
      
      To resolve O_DIRECT related deadlock problem, this patch re-introduces
      iint->mutex. But to eliminate the original chmod() related deadlock
      problem, this patch eliminates the requirement for chmod hooks to take
      the iint->mutex by introducing additional atomic iint->attr_flags to
      indicate calling of the hooks. The allowed locking order is to take
      the iint->mutex first and then the i_rwsem.
      
      Original flags were cleared in chmod(), setxattr() or removwxattr()
      hooks and tested when file was closed or opened again. New atomic flags
      are set or cleared in those hooks and tested to clear iint->flags on
      close or on open.
      
      Atomic flags are following:
      * IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown,
        chgrp) and file attributes have changed. On file open, it causes IMA
        to clear iint->flags to re-evaluate policy and perform IMA functions
        again.
      * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
        and extended attributes have changed. On file open, it causes IMA to
        clear iint->flags IMA_DONE_MASK to re-appraise.
      * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
        It is cleared if file policy changes and no update is needed.
      * IMA_DIGSIG - indicates that file security.ima has signature and file
        security.ima must not update to file has on file close.
      * IMA_MUST_MEASURE - indicates the file is in the measurement policy.
      
      Fixes: Commit 65523218 ("xfs: remove i_iolock and use i_rwsem in
      the VFS inode instead")
      Signed-off-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      281c07f3
    • Matthew Garrett's avatar
      EVM: Add support for portable signature format · e0998633
      Matthew Garrett authored
      commit 50b97748 upstream.
      
      The EVM signature includes the inode number and (optionally) the
      filesystem UUID, making it impractical to ship EVM signatures in
      packages. This patch adds a new portable format intended to allow
      distributions to include EVM signatures. It is identical to the existing
      format but hardcodes the inode and generation numbers to 0 and does not
      include the filesystem UUID even if the kernel is configured to do so.
      
      Removing the inode means that the metadata and signature from one file
      could be copied to another file without invalidating it. This is avoided
      by ensuring that an IMA xattr is present during EVM validation.
      
      Portable signatures are intended to be immutable - ie, they will never
      be transformed into HMACs.
      
      Based on earlier work by Dmitry Kasatkin and Mikhail Kurinnoi.
      Signed-off-by: default avatarMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0998633
    • Mimi Zohar's avatar
      ima: always measure and audit files in policy · de72a0f9
      Mimi Zohar authored
      commit f3cc6b25 upstream.
      
      All files matching a "measure" rule must be included in the IMA
      measurement list, even when the file hash cannot be calculated.
      Similarly, all files matching an "audit" rule must be audited, even when
      the file hash can not be calculated.
      
      The file data hash field contained in the IMA measurement list template
      data will contain 0's instead of the actual file hash digest.
      
      Note:
      In general, adding, deleting or in anyway changing which files are
      included in the IMA measurement list is not a good idea, as it might
      result in not being able to unseal trusted keys sealed to a specific
      TPM PCR value.  This patch not only adds file measurements that were
      not previously measured, but specifies that the file hash value for
      these files will be 0's.
      
      As the IMA measurement list ordering is not consistent from one boot
      to the next, it is unlikely that anyone is sealing keys based on the
      IMA measurement list.  Remote attestation servers should be able to
      process these new measurement records, but might complain about
      these unknown records.
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de72a0f9