1. 25 Jun, 2019 1 commit
  2. 09 Jun, 2019 1 commit
  3. 25 May, 2019 2 commits
  4. 16 May, 2019 1 commit
  5. 08 May, 2019 1 commit
  6. 04 May, 2019 1 commit
    • Paulo Alcantara's avatar
      selinux: use kernel linux/socket.h for genheaders and mdp · 760f8522
      Paulo Alcantara authored
      commit dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e upstream.
      
      When compiling genheaders and mdp from a newer host kernel, the
      following error happens:
      
          In file included from scripts/selinux/genheaders/genheaders.c:18:
          ./security/selinux/include/classmap.h:238:2: error: #error New
          address family defined, please update secclass_map.  #error New
          address family defined, please update secclass_map.  ^~~~~
          make[3]: *** [scripts/Makefile.host:107:
          scripts/selinux/genheaders/genheaders] Error 1 make[2]: ***
          [scripts/Makefile.build:599: scripts/selinux/genheaders] Error 2
          make[1]: *** [scripts/Makefile.build:599: scripts/selinux] Error 2
          make[1]: *** Waiting for unfinished jobs....
      
      Instead of relying on the host definition, include linux/socket.h in
      classmap.h to have PF_MAX.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarPaulo Alcantara <paulo@paulo.ac>
      Acked-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: manually merge in mdp.c, subject line tweaks]
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      760f8522
  7. 27 Apr, 2019 1 commit
  8. 05 Apr, 2019 1 commit
    • Ondrej Mosnacek's avatar
      selinux: do not override context on context mounts · 0ce68e86
      Ondrej Mosnacek authored
      [ Upstream commit 53e0c2aa9a59a48e3798ef193d573ade85aa80f5 ]
      
      Ignore all selinux_inode_notifysecctx() calls on mounts with SBLABEL_MNT
      flag unset. This is achived by returning -EOPNOTSUPP for this case in
      selinux_inode_setsecurtity() (because that function should not be called
      in such case anyway) and translating this error to 0 in
      selinux_inode_notifysecctx().
      
      This fixes behavior of kernfs-based filesystems when mounted with the
      'context=' option. Before this patch, if a node's context had been
      explicitly set to a non-default value and later the filesystem has been
      remounted with the 'context=' option, then this node would show up as
      having the manually-set context and not the mount-specified one.
      
      Steps to reproduce:
          # mount -t cgroup2 cgroup2 /sys/fs/cgroup/unified
          # chcon unconfined_u:object_r:user_home_t:s0 /sys/fs/cgroup/unified/cgroup.stat
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.threads
          # umount /sys/fs/cgroup/unified
          # mount -o context=system_u:object_r:tmpfs_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified
      
      Result before:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.threads
      
      Result after:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads
      Signed-off-by: 's avatarOndrej Mosnacek <omosnace@redhat.com>
      Reviewed-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0ce68e86
  9. 23 Mar, 2019 2 commits
    • J. Bruce Fields's avatar
      security/selinux: fix SECURITY_LSM_NATIVE_LABELS on reused superblock · af9e57ba
      J. Bruce Fields authored
      commit 3815a245b50124f0865415dcb606a034e97494d4 upstream.
      
      In the case when we're reusing a superblock, selinux_sb_clone_mnt_opts()
      fails to set set_kern_flags, with the result that
      nfs_clone_sb_security() incorrectly clears NFS_CAP_SECURITY_LABEL.
      
      The result is that if you mount the same NFS filesystem twice, NFS
      security labels are turned off, even if they would work fine if you
      mounted the filesystem only once.
      
      ("fixes" may be not exactly the right tag, it may be more like
      "fixed-other-cases-but-missed-this-one".)
      
      Cc: Scott Mayhew <smayhew@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 0b4d3452 "security/selinux: allow security_sb_clone_mnt_opts..."
      Signed-off-by: 's avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af9e57ba
    • David Howells's avatar
      keys: Fix dependency loop between construction record and auth key · 7b1386a3
      David Howells authored
      [ Upstream commit 822ad64d7e46a8e2c8b8a796738d7b657cbb146d ]
      
      In the request_key() upcall mechanism there's a dependency loop by which if
      a key type driver overrides the ->request_key hook and the userspace side
      manages to lose the authorisation key, the auth key and the internal
      construction record (struct key_construction) can keep each other pinned.
      
      Fix this by the following changes:
      
       (1) Killing off the construction record and using the auth key instead.
      
       (2) Including the operation name in the auth key payload and making the
           payload available outside of security/keys/.
      
       (3) The ->request_key hook is given the authkey instead of the cons
           record and operation name.
      
      Changes (2) and (3) allow the auth key to naturally be cleaned up if the
      keyring it is in is destroyed or cleared or the auth key is unlinked.
      
      Fixes: 7ee02a316600 ("keys: Fix dependency loop between construction record and auth key")
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      7b1386a3
  10. 19 Mar, 2019 1 commit
    • Al Viro's avatar
      missing barriers in some of unix_sock ->addr and ->path accesses · 727a2619
      Al Viro authored
      [ Upstream commit ae3b564179bfd06f32d051b9e5d72ce4b2a07c37 ]
      
      Several u->addr and u->path users are not holding any locks in
      common with unix_bind().  unix_state_lock() is useless for those
      purposes.
      
      u->addr is assign-once and *(u->addr) is fully set up by the time
      we set u->addr (all under unix_table_lock).  u->path is also
      set in the same critical area, also before setting u->addr, and
      any unix_sock with ->path filled will have non-NULL ->addr.
      
      So setting ->addr with smp_store_release() is all we need for those
      "lockless" users - just have them fetch ->addr with smp_load_acquire()
      and don't even bother looking at ->path if they see NULL ->addr.
      
      Users of ->addr and ->path fall into several classes now:
          1) ones that do smp_load_acquire(u->addr) and access *(u->addr)
      and u->path only if smp_load_acquire() has returned non-NULL.
          2) places holding unix_table_lock.  These are guaranteed that
      *(u->addr) is seen fully initialized.  If unix_sock is in one of the
      "bound" chains, so's ->path.
          3) unix_sock_destructor() using ->addr is safe.  All places
      that set u->addr are guaranteed to have seen all stores *(u->addr)
      while holding a reference to u and unix_sock_destructor() is called
      when (atomic) refcount hits zero.
          4) unix_release_sock() using ->path is safe.  unix_bind()
      is serialized wrt unix_release() (normally - by struct file
      refcount), and for the instances that had ->path set by unix_bind()
      unix_release_sock() comes from unix_release(), so they are fine.
      Instances that had it set in unix_stream_connect() either end up
      attached to a socket (in unix_accept()), in which case the call
      chain to unix_release_sock() and serialization are the same as in
      the previous case, or they never get accept'ed and unix_release_sock()
      is called when the listener is shut down and its queue gets purged.
      In that case the listener's queue lock provides the barriers needed -
      unix_stream_connect() shoves our unix_sock into listener's queue
      under that lock right after having set ->path and eventual
      unix_release_sock() caller picks them from that queue under the
      same lock right before calling unix_release_sock().
          5) unix_find_other() use of ->path is pointless, but safe -
      it happens with successful lookup by (abstract) name, so ->path.dentry
      is guaranteed to be NULL there.
      earlier-variant-reviewed-by: 's avatar"Paul E. McKenney" <paulmck@linux.ibm.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      727a2619
  11. 13 Mar, 2019 1 commit
  12. 27 Feb, 2019 2 commits
    • Eric Biggers's avatar
      KEYS: always initialize keyring_index_key::desc_len · 50d039d9
      Eric Biggers authored
      commit ede0fa98a900e657d1fcd80b50920efc896c1a4c upstream.
      
      syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin()
      called from construct_alloc_key() during sys_request_key(), because the
      length of the key description was never calculated.
      
      The problem is that we rely on ->desc_len being initialized by
      search_process_keyrings(), specifically by search_nested_keyrings().
      But, if the process isn't subscribed to any keyrings that never happens.
      
      Fix it by always initializing keyring_index_key::desc_len as soon as the
      description is set, like we already do in some places.
      
      The following program reproduces the BUG_ON() when it's run as root and
      no session keyring has been installed.  If it doesn't work, try removing
      pam_keyinit.so from /etc/pam.d/login and rebooting.
      
          #include <stdlib.h>
          #include <unistd.h>
          #include <keyutils.h>
      
          int main(void)
          {
                  int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING);
      
                  keyctl_setperm(id, KEY_OTH_WRITE);
                  setreuid(5000, 5000);
                  request_key("user", "desc", "", id);
          }
      
      Reported-by: syzbot+ec24e95ea483de0a24da@syzkaller.appspotmail.com
      Fixes: b2a4df20 ("KEYS: Expand the capacity of a keyring")
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50d039d9
    • Eric Biggers's avatar
      KEYS: allow reaching the keys quotas exactly · fe303ba7
      Eric Biggers authored
      commit a08bf91ce28ed3ae7b6fef35d843fef8dc8c2cd9 upstream.
      
      If the sysctl 'kernel.keys.maxkeys' is set to some number n, then
      actually users can only add up to 'n - 1' keys.  Likewise for
      'kernel.keys.maxbytes' and the root_* versions of these sysctls.  But
      these sysctls are apparently supposed to be *maximums*, as per their
      names and all documentation I could find -- the keyrings(7) man page,
      Documentation/security/keys/core.rst, and all the mentions of EDQUOT
      meaning that the key quota was *exceeded* (as opposed to reached).
      
      Thus, fix the code to allow reaching the quotas exactly.
      
      Fixes: 0b77f5bf ("keys: make the keyring quotas controllable through /proc/sys")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe303ba7
  13. 12 Feb, 2019 1 commit
    • Zoran Markovic's avatar
      smack: fix access permissions for keyring · 9c58ef24
      Zoran Markovic authored
      [ Upstream commit 5b841bfab695e3b8ae793172a9ff7990f99cc3e2 ]
      
      Function smack_key_permission() only issues smack requests for the
      following operations:
       - KEY_NEED_READ (issues MAY_READ)
       - KEY_NEED_WRITE (issues MAY_WRITE)
       - KEY_NEED_LINK (issues MAY_WRITE)
       - KEY_NEED_SETATTR (issues MAY_WRITE)
      A blank smack request is issued in all other cases, resulting in
      smack access being granted if there is any rule defined between
      subject and object, or denied with -EACCES otherwise.
      
      Request MAY_READ access for KEY_NEED_SEARCH and KEY_NEED_VIEW.
      Fix the logic in the unlikely case when both MAY_READ and
      MAY_WRITE are needed. Validate access permission field for valid
      contents.
      Signed-off-by: 's avatarZoran Markovic <zmarkovic@sierrawireless.com>
      Signed-off-by: 's avatarCasey Schaufler <casey@schaufler-ca.com>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      9c58ef24
  14. 26 Jan, 2019 1 commit
    • Ondrej Mosnacek's avatar
      selinux: always allow mounting submounts · fbbfb5c6
      Ondrej Mosnacek authored
      [ Upstream commit 2cbdcb882f97a45f7475c67ac6257bbc16277dfe ]
      
      If a superblock has the MS_SUBMOUNT flag set, we should always allow
      mounting it. These mounts are done automatically by the kernel either as
      part of mounting some parent mount (e.g. debugfs always mounts tracefs
      under "tracing" for compatibility) or they are mounted automatically as
      needed on subdirectory accesses (e.g. NFS crossmnt mounts). Since such
      automounts are either an implicit consequence of the parent mount (which
      is already checked) or they can happen during regular accesses (where it
      doesn't make sense to check against the current task's context), the
      mount permission check should be skipped for them.
      
      Without this patch, attempts to access contents of an automounted
      directory can cause unexpected SELinux denials.
      
      In the current kernel tree, the MS_SUBMOUNT flag is set only via
      vfs_submount(), which is called only from the following places:
       - AFS, when automounting special "symlinks" referencing other cells
       - CIFS, when automounting "referrals"
       - NFS, when automounting subtrees
       - debugfs, when automounting tracefs
      
      In all cases the submounts are meant to be transparent to the user and
      it makes sense that if mounting the master is allowed, then so should be
      the automounts. Note that CAP_SYS_ADMIN capability checking is already
      skipped for (SB_KERNMOUNT|SB_SUBMOUNT) in:
       - sget_userns() in fs/super.c:
      	if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) &&
      	    !(type->fs_flags & FS_USERNS_MOUNT) &&
      	    !capable(CAP_SYS_ADMIN))
      		return ERR_PTR(-EPERM);
       - sget() in fs/super.c:
              /* Ensure the requestor has permissions over the target filesystem */
              if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !ns_capable(user_ns, CAP_SYS_ADMIN))
                      return ERR_PTR(-EPERM);
      
      Verified internally on patched RHEL 7.6 with a reproducer using
      NFS+httpd and selinux-tesuite.
      
      Fixes: 93faccbb ("fs: Better permission checking for submounts")
      Signed-off-by: 's avatarOndrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      fbbfb5c6
  15. 23 Jan, 2019 3 commits
  16. 13 Jan, 2019 1 commit
    • Ondrej Mosnacek's avatar
      selinux: policydb - fix byte order and alignment issues · 2524f5d6
      Ondrej Mosnacek authored
      commit 5df275cd4cf51c86d49009f1397132f284ba515e upstream.
      
      Do the LE conversions before doing the Infiniband-related range checks.
      The incorrect checks are otherwise causing a failure to load any policy
      with an ibendportcon rule on BE systems. This can be reproduced by
      running (on e.g. ppc64):
      
      cat >my_module.cil <<EOF
      (type test_ibendport_t)
      (roletype object_r test_ibendport_t)
      (ibendportcon mlx4_0 1 (system_u object_r test_ibendport_t ((s0) (s0))))
      EOF
      semodule -i my_module.cil
      
      Also, fix loading/storing the 64-bit subnet prefix for OCON_IBPKEY to
      use a correctly aligned buffer.
      
      Finally, do not use the 'nodebuf' (u32) buffer where 'buf' (__le32)
      should be used instead.
      
      Tested internally on a ppc64 machine with a RHEL 7 kernel with this
      patch applied.
      
      Cc: Daniel Jurgens <danielj@mellanox.com>
      Cc: Eli Cohen <eli@mellanox.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: <stable@vger.kernel.org> # 4.13+
      Fixes: a806f7a1 ("selinux: Create policydb version for Infiniband support")
      Signed-off-by: 's avatarOndrej Mosnacek <omosnace@redhat.com>
      Acked-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2524f5d6
  17. 01 Dec, 2018 5 commits
    • 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: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarJames Morris <jmorris@namei.org>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: 's 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: 's avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: 's 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: 's avatarMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: 's 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: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: 's avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de72a0f9
    • Tetsuo Handa's avatar
      selinux: Add __GFP_NOWARN to allocation at str_read() · 9520db16
      Tetsuo Handa authored
      commit 4458bba09788e70e8fb39ad003f087cd9dfbd6ac upstream.
      
      syzbot is hitting warning at str_read() [1] because len parameter can
      become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for
      this case.
      
      [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0Signed-off-by: 's avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: 's avatarsyzbot <syzbot+ac488b9811036cea7ea0@syzkaller.appspotmail.com>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9520db16
  18. 27 Nov, 2018 1 commit
    • Zubin Mithra's avatar
      apparmor: Fix uninitialized value in aa_split_fqname · d0a636aa
      Zubin Mithra authored
      [ Upstream commit 250f2da49cb8e582215a65c03f50e8ddf5cd119c ]
      
      Syzkaller reported a OOB-read with the stacktrace below. This occurs
      inside __aa_lookupn_ns as `n` is not initialized. `n` is obtained from
      aa_splitn_fqname. In cases where `name` is invalid, aa_splitn_fqname
      returns without initializing `ns_name` and `ns_len`.
      
      Fix this by always initializing `ns_name` and `ns_len`.
      
      	__dump_stack lib/dump_stack.c:77 [inline]
      	dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
      	print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
      	kasan_report_error mm/kasan/report.c:354 [inline]
      	kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
      	__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
      	memcmp+0xe3/0x160 lib/string.c:861
      	strnstr+0x4b/0x70 lib/string.c:934
      	__aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209
      	aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240
      	aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468
      	fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844
      	aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908
      	aa_label_parse+0x42/0x50 security/apparmor/label.c:1943
      	aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362
      	apparmor_setprocattr+0xaa4/0x1150 security/apparmor/lsm.c:658
      	security_setprocattr+0x66/0xc0 security/security.c:1298
      	proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555
      	__vfs_write+0x119/0x9f0 fs/read_write.c:485
      	vfs_write+0x1fc/0x560 fs/read_write.c:549
      	ksys_write+0x101/0x260 fs/read_write.c:598
      	__do_sys_write fs/read_write.c:610 [inline]
      	__se_sys_write fs/read_write.c:607 [inline]
      	__x64_sys_write+0x73/0xb0 fs/read_write.c:607
      	do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
      	entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 3b0aaf58 ("apparmor: add lib fn to find the "split" for fqnames")
      Reported-by: syzbot+61e4b490d9d2da591b50@syzkaller.appspotmail.com
      Signed-off-by: 's avatarZubin Mithra <zsm@chromium.org>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d0a636aa
  19. 13 Nov, 2018 1 commit
  20. 29 Sep, 2018 1 commit
  21. 26 Sep, 2018 3 commits
  22. 15 Sep, 2018 1 commit
  23. 09 Sep, 2018 1 commit
    • Eddie.Horng's avatar
      cap_inode_getsecurity: use d_find_any_alias() instead of d_find_alias() · 5a842ecc
      Eddie.Horng authored
      commit 355139a8 upstream.
      
      The code in cap_inode_getsecurity(), introduced by commit 8db6c34f
      ("Introduce v3 namespaced file capabilities"), should use
      d_find_any_alias() instead of d_find_alias() do handle unhashed dentry
      correctly. This is needed, for example, if execveat() is called with an
      open but unlinked overlayfs file, because overlayfs unhashes dentry on
      unlink.
      This is a regression of real life application, first reported at
      https://www.spinics.net/lists/linux-unionfs/msg05363.html
      
      Below reproducer and setup can reproduce the case.
        const char* exec="echo";
        const char *newargv[] = { "echo", "hello", NULL};
        const char *newenviron[] = { NULL };
        int fd, err;
      
        fd = open(exec, O_PATH);
        unlink(exec);
        err = syscall(322/*SYS_execveat*/, fd, "", newargv, newenviron,
      AT_EMPTY_PATH);
        if(err<0)
          fprintf(stderr, "execveat: %s\n", strerror(errno));
      
      gcc compile into ~/test/a.out
      mount -t overlay -orw,lowerdir=/mnt/l,upperdir=/mnt/u,workdir=/mnt/w
      none /mnt/m
      cd /mnt/m
      cp /bin/echo .
      ~/test/a.out
      
      Expected result:
      hello
      Actually result:
      execveat: Invalid argument
      dmesg:
      Invalid argument reading file caps for /dev/fd/3
      
      The 2nd reproducer and setup emulates similar case but for
      regular filesystem:
        const char* exec="echo";
        int fd, err;
        char buf[256];
      
        fd = open(exec, O_RDONLY);
        unlink(exec);
        err = fgetxattr(fd, "security.capability", buf, 256);
        if(err<0)
          fprintf(stderr, "fgetxattr: %s\n", strerror(errno));
      
      gcc compile into ~/test_fgetxattr
      
      cd /tmp
      cp /bin/echo .
      ~/test_fgetxattr
      
      Result:
      fgetxattr: Invalid argument
      
      On regular filesystem, for example, ext4 read xattr from
      disk and return to execveat(), will not trigger this issue, however,
      the overlay attr handler pass real dentry to vfs_getxattr() will.
      This reproducer calls fgetxattr() with an unlinked fd, involkes
      vfs_getxattr() then reproduced the case that d_find_alias() in
      cap_inode_getsecurity() can't find the unlinked dentry.
      Suggested-by: 's avatarAmir Goldstein <amir73il@gmail.com>
      Acked-by: 's avatarAmir Goldstein <amir73il@gmail.com>
      Acked-by: 's avatarSerge E. Hallyn <serge@hallyn.com>
      Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities")
      Cc: <stable@vger.kernel.org> # v4.14
      Signed-off-by: 's avatarEddie Horng <eddie.horng@mediatek.com>
      Signed-off-by: 's avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a842ecc
  24. 24 Aug, 2018 1 commit
  25. 03 Aug, 2018 1 commit
  26. 05 Jun, 2018 1 commit
    • Sachin Grover's avatar
      selinux: KASAN: slab-out-of-bounds in xattr_getsecurity · 9808c97d
      Sachin Grover authored
      commit efe3de79 upstream.
      
      Call trace:
       [<ffffff9203a8d7a8>] dump_backtrace+0x0/0x428
       [<ffffff9203a8dbf8>] show_stack+0x28/0x38
       [<ffffff920409bfb8>] dump_stack+0xd4/0x124
       [<ffffff9203d187e8>] print_address_description+0x68/0x258
       [<ffffff9203d18c00>] kasan_report.part.2+0x228/0x2f0
       [<ffffff9203d1927c>] kasan_report+0x5c/0x70
       [<ffffff9203d1776c>] check_memory_region+0x12c/0x1c0
       [<ffffff9203d17cdc>] memcpy+0x34/0x68
       [<ffffff9203d75348>] xattr_getsecurity+0xe0/0x160
       [<ffffff9203d75490>] vfs_getxattr+0xc8/0x120
       [<ffffff9203d75d68>] getxattr+0x100/0x2c8
       [<ffffff9203d76fb4>] SyS_fgetxattr+0x64/0xa0
       [<ffffff9203a83f70>] el0_svc_naked+0x24/0x28
      
      If user get root access and calls security.selinux setxattr() with an
      embedded NUL on a file and then if some process performs a getxattr()
      on that file with a length greater than the actual length of the string,
      it would result in a panic.
      
      To fix this, add the actual length of the string to the security context
      instead of the length passed by the userspace process.
      Signed-off-by: 's avatarSachin Grover <sgrover@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9808c97d
  27. 30 May, 2018 3 commits
    • Petr Vorel's avatar
      ima: Fallback to the builtin hash algorithm · cd2399b4
      Petr Vorel authored
      [ Upstream commit ab60368a ]
      
      IMA requires having it's hash algorithm be compiled-in due to it's
      early use.  The default IMA algorithm is protected by Kconfig to be
      compiled-in.
      
      The ima_hash kernel parameter allows to choose the hash algorithm. When
      the specified algorithm is not available or available as a module, IMA
      initialization fails, which leads to a kernel panic (mknodat syscall calls
      ima_post_path_mknod()).  Therefore as fallback we force IMA to use
      the default builtin Kconfig hash algorithm.
      
      Fixed crash:
      
      $ grep CONFIG_CRYPTO_MD4 .config
      CONFIG_CRYPTO_MD4=m
      
      [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=74ae8202-9ca7-4e39-813b-22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4
      ...
      [    1.545190] ima: Can not allocate md4 (reason: -2)
      ...
      [    2.610120] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [    2.611903] IP: ima_match_policy+0x23/0x390
      [    2.612967] PGD 0 P4D 0
      [    2.613080] Oops: 0000 [#1] SMP
      [    2.613080] Modules linked in: autofs4
      [    2.613080] Supported: Yes
      [    2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1
      [    2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      [    2.613080] task: ffff88003e2d0040 task.stack: ffffc90000190000
      [    2.613080] RIP: 0010:ima_match_policy+0x23/0x390
      [    2.613080] RSP: 0018:ffffc90000193e88 EFLAGS: 00010296
      [    2.613080] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000004
      [    2.613080] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffff880037071728
      [    2.613080] RBP: 0000000000008000 R08: 0000000000000000 R09: 0000000000000000
      [    2.613080] R10: 0000000000000008 R11: 61c8864680b583eb R12: 00005580ff10086f
      [    2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000008000
      [    2.613080] FS:  00007f5c1da08940(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
      [    2.613080] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    2.613080] CR2: 0000000000000000 CR3: 0000000037002000 CR4: 00000000003406f0
      [    2.613080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [    2.613080] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [    2.613080] Call Trace:
      [    2.613080]  ? shmem_mknod+0xbf/0xd0
      [    2.613080]  ima_post_path_mknod+0x1c/0x40
      [    2.613080]  SyS_mknod+0x210/0x220
      [    2.613080]  entry_SYSCALL_64_fastpath+0x1a/0xa5
      [    2.613080] RIP: 0033:0x7f5c1bfde570
      [    2.613080] RSP: 002b:00007ffde1c90dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000085
      [    2.613080] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c1bfde570
      [    2.613080] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00005580ff10086f
      [    2.613080] RBP: 00007ffde1c91040 R08: 00005580ff10086f R09: 0000000000000000
      [    2.613080] R10: 0000000000104000 R11: 0000000000000246 R12: 00005580ffb99660
      [    2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002
      [    2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20
      [    2.613080] RIP: ima_match_policy+0x23/0x390 RSP: ffffc90000193e88
      [    2.613080] CR2: 0000000000000000
      [    2.613080] ---[ end trace 9a9f0a8a73079f6a ]---
      [    2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      [    2.673052]
      [    2.675337] Kernel Offset: disabled
      [    2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      Signed-off-by: 's avatarPetr Vorel <pvorel@suse.cz>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd2399b4
    • Jiandi An's avatar
      ima: Fix Kconfig to select TPM 2.0 CRB interface · bc72e4fc
      Jiandi An authored
      [ Upstream commit fac37c62 ]
      
      TPM_CRB driver provides TPM CRB 2.0 support.  If it is built as a
      module, the TPM chip is registered after IMA init.  tpm_pcr_read() in
      IMA fails and displays the following message even though eventually
      there is a TPM chip on the system.
      
      ima: No TPM chip found, activating TPM-bypass! (rc=-19)
      
      Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is built in the kernel
      and initializes before IMA.
      Signed-off-by: 's avatarJiandi An <anjiandi@codeaurora.org>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc72e4fc
    • Randy Dunlap's avatar
      integrity/security: fix digsig.c build error with header file · 09897fcb
      Randy Dunlap authored
      [ Upstream commit 120f3b11 ]
      
      security/integrity/digsig.c has build errors on some $ARCH due to a
      missing header file, so add it.
      
        security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
      Reported-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: linux-integrity@vger.kernel.org
      Link: http://kisskb.ellerman.id.au/kisskb/head/13396/Signed-off-by: 's avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: 's avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09897fcb