1. 09 9月, 2020 2 次提交
  2. 21 7月, 2020 2 次提交
    • B
      ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime · 311aa6aa
      Bruno Meneguele 提交于
      The IMA_APPRAISE_BOOTPARAM config allows enabling different "ima_appraise="
      modes - log, fix, enforce - at run time, but not when IMA architecture
      specific policies are enabled.  This prevents properly labeling the
      filesystem on systems where secure boot is supported, but not enabled on the
      platform.  Only when secure boot is actually enabled should these IMA
      appraise modes be disabled.
      
      This patch removes the compile time dependency and makes it a runtime
      decision, based on the secure boot state of that platform.
      
      Test results as follows:
      
      -> x86-64 with secure boot enabled
      
      [    0.015637] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
      [    0.015668] ima: Secure boot enabled: ignoring ima_appraise=fix boot parameter option
      
      -> powerpc with secure boot disabled
      
      [    0.000000] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
      [    0.000000] Secure boot mode disabled
      
      -> Running the system without secure boot and with both options set:
      
      CONFIG_IMA_APPRAISE_BOOTPARAM=y
      CONFIG_IMA_ARCH_POLICY=y
      
      Audit prompts "missing-hash" but still allow execution and, consequently,
      filesystem labeling:
      
      type=INTEGRITY_DATA msg=audit(07/09/2020 12:30:27.778:1691) : pid=4976
      uid=root auid=root ses=2
      subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data
      cause=missing-hash comm=bash name=/usr/bin/evmctl dev="dm-0" ino=493150
      res=no
      
      Cc: stable@vger.kernel.org
      Fixes: d958083a ("x86/ima: define arch_get_ima_policy() for x86")
      Signed-off-by: NBruno Meneguele <bmeneg@redhat.com>
      Cc: stable@vger.kernel.org # 5.0
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      311aa6aa
    • T
      ima: Support additional conditionals in the KEXEC_CMDLINE hook function · 4834177e
      Tyler Hicks 提交于
      Take the properties of the kexec kernel's inode and the current task
      ownership into consideration when matching a KEXEC_CMDLINE operation to
      the rules in the IMA policy. This allows for some uniformity when
      writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK,
      and KEXEC_CMDLINE operations.
      
      Prior to this patch, it was not possible to write a set of rules like
      this:
      
       dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
       dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
       dont_measure func=KEXEC_CMDLINE obj_type=foo_t
       measure func=KEXEC_KERNEL_CHECK
       measure func=KEXEC_INITRAMFS_CHECK
       measure func=KEXEC_CMDLINE
      
      The inode information associated with the kernel being loaded by a
      kexec_kernel_load(2) syscall can now be included in the decision to
      measure or not
      
      Additonally, the uid, euid, and subj_* conditionals can also now be
      used in KEXEC_CMDLINE rules. There was no technical reason as to why
      those conditionals weren't being considered previously other than
      ima_match_rules() didn't have a valid inode to use so it immediately
      bailed out for KEXEC_CMDLINE operations rather than going through the
      full list of conditional comparisons.
      Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: kexec@lists.infradead.org
      Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      4834177e
  3. 12 12月, 2019 1 次提交
    • L
      IMA: Add support to limit measuring keys · e9085e0a
      Lakshmi Ramasubramanian 提交于
      Limit measuring keys to those keys being loaded onto a given set of
      keyrings only and when the user id (uid) matches if uid is specified
      in the policy.
      
      This patch defines a new IMA policy option namely "keyrings=" that
      can be used to specify a set of keyrings. If this option is specified
      in the policy for "measure func=KEY_CHECK" then only the keys
      loaded onto a keyring given in the "keyrings=" option are measured.
      
      If uid is specified in the policy then the key is measured only if
      the current user id matches the one specified in the policy.
      
      Added a new parameter namely "keyring" (name of the keyring) to
      process_buffer_measurement(). The keyring name is passed to
      ima_get_action() to determine the required action.
      ima_match_rules() is updated to check keyring in the policy, if
      specified, for KEY_CHECK function.
      Signed-off-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      e9085e0a
  4. 12 11月, 2019 1 次提交
    • N
      ima: Check against blacklisted hashes for files with modsig · 273df864
      Nayna Jain 提交于
      Asymmetric private keys are used to sign multiple files. The kernel
      currently supports checking against blacklisted keys. However, if the
      public key is blacklisted, any file signed by the blacklisted key will
      automatically fail signature verification. Blacklisting the public key
      is not fine enough granularity, as we might want to only blacklist a
      particular file.
      
      This patch adds support for checking against the blacklisted hash of
      the file, without the appended signature, based on the IMA policy. It
      defines a new policy option "appraise_flag=check_blacklist".
      
      In addition to the blacklisted binary hashes stored in the firmware
      "dbx" variable, the Linux kernel may be configured to load blacklisted
      binary hashes onto the .blacklist keyring as well. The following
      example shows how to blacklist a specific kernel module hash.
      
        $ sha256sum kernel/kheaders.ko
        77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
        kernel/kheaders.ko
      
        $ grep BLACKLIST .config
        CONFIG_SYSTEM_BLACKLIST_KEYRING=y
        CONFIG_SYSTEM_BLACKLIST_HASH_LIST="blacklist-hash-list"
      
        $ cat certs/blacklist-hash-list
        "bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3"
      
      Update the IMA custom measurement and appraisal policy
      rules (/etc/ima-policy):
      
        measure func=MODULE_CHECK template=ima-modsig
        appraise func=MODULE_CHECK appraise_flag=check_blacklist
        appraise_type=imasig|modsig
      
      After building, installing, and rebooting the kernel:
      
         545660333 ---lswrv      0     0   \_ blacklist:
        bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
      
        measure func=MODULE_CHECK template=ima-modsig
        appraise func=MODULE_CHECK appraise_flag=check_blacklist
        appraise_type=imasig|modsig
      
        modprobe: ERROR: could not insert 'kheaders': Permission denied
      
        10 0c9834db5a0182c1fb0cdc5d3adcf11a11fd83dd ima-sig
        sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
        2 /usr/lib/modules/5.4.0-rc3+/kernel/kernel/kheaders.ko
      
        10 82aad2bcc3fa8ed94762356b5c14838f3bcfa6a0 ima-modsig
        sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
        2 /usr/lib/modules/5.4.0rc3+/kernel/kernel/kheaders.ko  sha256:77fa889b3
        5a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
        3082029a06092a864886f70d010702a082028b30820287020101310d300b0609608648
        016503040201300b06092a864886f70d01070131820264....
      
        10 25b72217cc1152b44b134ce2cd68f12dfb71acb3 ima-buf
        sha256:8b58427fedcf8f4b20bc8dc007f2e232bf7285d7b93a66476321f9c2a3aa132
        b blacklisted-hash
        77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      [zohar@linux.ibm.com: updated patch description]
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/1572492694-6520-8-git-send-email-zohar@linux.ibm.com
      273df864
  5. 06 8月, 2019 3 次提交
  6. 01 7月, 2019 1 次提交
    • 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
  7. 20 6月, 2019 1 次提交
  8. 05 6月, 2019 1 次提交
  9. 23 2月, 2019 1 次提交
    • G
      security: mark expected switch fall-throughs and add a missing break · 09186e50
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warnings:
      
      security/integrity/ima/ima_template_lib.c:85:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:940:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:943:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:972:21: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/integrity/ima/ima_policy.c:974:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/smack/smack_lsm.c:3391:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
      security/apparmor/domain.c:569:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Also, add a missing break statement to fix the following warning:
      
      security/integrity/ima/ima_appraise.c:116:26: warning: this statement may fall through [-Wimplicit-fallthrough=]
      Acked-by: NJohn Johansen <john.johansen@canonical.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Acked-by: NMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: NJames Morris <james.morris@microsoft.com>
      09186e50
  10. 13 12月, 2018 2 次提交
    • N
      ima: Support platform keyring for kernel appraisal · d7cecb67
      Nayna Jain 提交于
      On secure boot enabled systems, the bootloader verifies the kernel
      image and possibly the initramfs signatures based on a set of keys. A
      soft reboot(kexec) of the system, with the same kernel image and
      initramfs, requires access to the original keys to verify the
      signatures.
      
      This patch allows IMA-appraisal access to those original keys, now
      loaded on the platform keyring, needed for verifying the kernel image
      and initramfs signatures.
      
      [zohar@linux.ibm.com: only use platform keyring if it's enabled (Thiago)]
      Signed-off-by: NNayna Jain <nayna@linux.ibm.com>
      Reviewed-by: NMimi Zohar <zohar@linux.ibm.com>
      Acked-by: NSerge Hallyn <serge@hallyn.com>
      Reviewed-by: NJames Morris <james.morris@microsoft.com>
      Reviewed-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      d7cecb67
    • P
      security: audit and remove any unnecessary uses of module.h · 876979c9
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.
      
      The advantage in removing such instances is that module.h itself
      sources about 15 other headers; adding significantly to what we feed
      cpp, and it can obscure what headers we are effectively using.
      
      Since module.h might have been the implicit source for init.h
      (for __init) and for export.h (for EXPORT_SYMBOL) we consider each
      instance for the presence of either and replace as needed.
      
      Cc: James Morris <jmorris@namei.org>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: John Johansen <john.johansen@canonical.com>
      Cc: Mimi Zohar <zohar@linux.ibm.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: linux-security-module@vger.kernel.org
      Cc: linux-integrity@vger.kernel.org
      Cc: keyrings@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJames Morris <james.morris@microsoft.com>
      876979c9
  11. 12 7月, 2018 1 次提交
  12. 25 3月, 2018 1 次提交
  13. 23 3月, 2018 3 次提交
    • M
      ima: fail signature verification based on policy · 9e67028e
      Mimi Zohar 提交于
      This patch addresses the fuse privileged mounted filesystems in
      environments which are unwilling to accept the risk of trusting the
      signature verification and want to always fail safe, but are for example
      using a pre-built kernel.
      
      This patch defines a new builtin policy named "fail_securely", which can
      be specified on the boot command line as an argument to "ima_policy=".
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Dongsu Park <dongsu@kinvolk.io>
      Cc: Alban Crequy <alban@kinvolk.io>
      Acked-by: NSerge Hallyn <serge@hallyn.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      9e67028e
    • M
      ima: fail file signature verification on non-init mounted filesystems · 57b56ac6
      Mimi Zohar 提交于
      FUSE can be mounted by unprivileged users either today with fusermount
      installed with setuid, or soon with the upcoming patches to allow FUSE
      mounts in a non-init user namespace.
      
      This patch addresses the new unprivileged non-init mounted filesystems,
      which are untrusted, by failing the signature verification.
      
      This patch defines two new flags SB_I_IMA_UNVERIFIABLE_SIGNATURE and
      SB_I_UNTRUSTED_MOUNTER.
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Dongsu Park <dongsu@kinvolk.io>
      Cc: Alban Crequy <alban@kinvolk.io>
      Acked-by: NSerge Hallyn <serge@hallyn.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      57b56ac6
    • M
      IMA: Support using new creds in appraisal policy · d906c10d
      Matthew Garrett 提交于
      The existing BPRM_CHECK functionality in IMA validates against the
      credentials of the existing process, not any new credentials that the
      child process may transition to. Add an additional CREDS_CHECK target
      and refactor IMA to pass the appropriate creds structure. In
      ima_bprm_check(), check with both the existing process credentials and
      the credentials that will be committed when the new process is started.
      This will not change behaviour unless the system policy is extended to
      include CREDS_CHECK targets - BPRM_CHECK will continue to check the same
      credentials that it did previously.
      
      After this patch, an IMA policy rule along the lines of:
      
      measure func=CREDS_CHECK subj_type=unconfined_t
      
      will trigger if a process is executed and runs as unconfined_t, ignoring
      the context of the parent process. This is in contrast to:
      
      measure func=BPRM_CHECK subj_type=unconfined_t
      
      which will trigger if the process that calls exec() is already executing
      in unconfined_t, ignoring the context that the child process executes
      into.
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      
      Changelog:
      - initialize ima_creds_status
      d906c10d
  14. 18 12月, 2017 1 次提交
    • M
      ima: support new "hash" and "dont_hash" policy actions · da1b0029
      Mimi Zohar 提交于
      The builtin ima_appraise_tcb policy, which is specified on the boot
      command line, can be replaced with a custom policy, normally early in
      the boot process.  Custom policies can be more restrictive in some ways,
      like requiring file signatures, but can be less restrictive in other
      ways, like not appraising mutable files.  With a less restrictive policy
      in place, files in the builtin policy might not be hashed and labeled
      with a security.ima hash.  On reboot, files which should be labeled in
      the ima_appraise_tcb are not labeled, possibly preventing the system
      from booting properly.
      
      To resolve this problem, this patch extends the existing IMA policy
      actions "measure", "dont_measure", "appraise", "dont_appraise", and
      "audit" with "hash" and "dont_hash".  The new "hash" action will write
      the file hash as security.ima, but without requiring the file to be
      appraised as well.
      
      For example, the builtin ima_appraise_tcb policy includes the rule,
      "appraise fowner=0".  Adding the "hash fowner=0" rule to a custom
      policy, will cause the needed file hashes to be calculated and written
      as security.ima xattrs.
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      da1b0029
  15. 12 12月, 2017 3 次提交
    • D
      ima: re-introduce own integrity cache lock · 0d73a552
      Dmitry Kasatkin 提交于
      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: NDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      0d73a552
    • M
      EVM: Add support for portable signature format · 50b97748
      Matthew Garrett 提交于
      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: NMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      50b97748
    • M
      ima: relax requiring a file signature for new files with zero length · b7e27bc1
      Mimi Zohar 提交于
      Custom policies can require file signatures based on LSM labels.  These
      files are normally created and only afterwards labeled, requiring them
      to be signed.
      
      Instead of requiring file signatures based on LSM labels, entire
      filesystems could require file signatures.  In this case, we need the
      ability of writing new files without requiring file signatures.
      
      The definition of a "new" file was originally defined as any file with
      a length of zero.  Subsequent patches redefined a "new" file to be based
      on the FILE_CREATE open flag.  By combining the open flag with a file
      size of zero, this patch relaxes the file signature requirement.
      
      Fixes: 1ac202e9 ima: accept previously set IMA_NEW_FILE
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      b7e27bc1
  16. 20 11月, 2017 1 次提交
    • R
      ima: do not update security.ima if appraisal status is not INTEGRITY_PASS · 020aae3e
      Roberto Sassu 提交于
      Commit b65a9cfc ("Untangling ima mess, part 2: deal with counters")
      moved the call of ima_file_check() from may_open() to do_filp_open() at a
      point where the file descriptor is already opened.
      
      This breaks the assumption made by IMA that file descriptors being closed
      belong to files whose access was granted by ima_file_check(). The
      consequence is that security.ima and security.evm are updated with good
      values, regardless of the current appraisal status.
      
      For example, if a file does not have security.ima, IMA will create it after
      opening the file for writing, even if access is denied. Access to the file
      will be allowed afterwards.
      
      Avoid this issue by checking the appraisal status before updating
      security.ima.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      020aae3e
  17. 09 11月, 2017 1 次提交
  18. 22 6月, 2017 4 次提交
  19. 07 3月, 2017 1 次提交
    • D
      ima: accept previously set IMA_NEW_FILE · 1ac202e9
      Daniel Glöckner 提交于
      Modifying the attributes of a file makes ima_inode_post_setattr reset
      the IMA cache flags. So if the file, which has just been created,
      is opened a second time before the first file descriptor is closed,
      verification fails since the security.ima xattr has not been written
      yet. We therefore have to look at the IMA_NEW_FILE even if the file
      already existed.
      
      With this patch there should no longer be an error when cat tries to
      open testfile:
      
      $ rm -f testfile
      $ ( echo test >&3 ; touch testfile ; cat testfile ) 3>testfile
      
      A file being new is no reason to accept that it is missing a digital
      signature demanded by the policy.
      Signed-off-by: NDaniel Glöckner <dg@emlix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      1ac202e9
  20. 14 11月, 2016 2 次提交
  21. 08 10月, 2016 1 次提交
  22. 16 9月, 2016 1 次提交
  23. 30 6月, 2016 2 次提交
  24. 01 5月, 2016 2 次提交
    • M
      ima: add support for creating files using the mknodat syscall · 05d1a717
      Mimi Zohar 提交于
      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: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Al Viro <<viro@zeniv.linux.org.uk>
      Tested-by: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      05d1a717
    • M
      ima: fix ima_inode_post_setattr · 42a4c603
      Mimi Zohar 提交于
      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: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Tested-by: NDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      42a4c603
  25. 21 2月, 2016 1 次提交