1. 05 Dec, 2018 37 commits
  2. 01 Dec, 2018 3 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