1. 30 May, 2018 1 commit
    • Sachin Grover's avatar
      selinux: KASAN: slab-out-of-bounds in xattr_getsecurity · efe3de79
      Sachin Grover authored
      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: default avatarSachin Grover <sgrover@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      efe3de79
  2. 24 May, 2018 1 commit
    • Eric W. Biederman's avatar
      capabilities: Allow privileged user in s_user_ns to set security.* xattrs · b1d749c5
      Eric W. Biederman authored
      A privileged user in s_user_ns will generally have the ability to
      manipulate the backing store and insert security.* xattrs into
      the filesystem directly. Therefore the kernel must be prepared to
      handle these xattrs from unprivileged mounts, and it makes little
      sense for commoncap to prevent writing these xattrs to the
      filesystem. The capability and LSM code have already been updated
      to appropriately handle xattrs from unprivileged mounts, so it
      is safe to loosen this restriction on setting xattrs.
      
      The exception to this logic is that writing xattrs to a mounted
      filesystem may also cause the LSM inode_post_setxattr or
      inode_setsecurity callbacks to be invoked. SELinux will deny the
      xattr update by virtue of applying mountpoint labeling to
      unprivileged userns mounts, and Smack will deny the writes for
      any user without global CAP_MAC_ADMIN, so loosening the
      capability check in commoncap is safe in this respect as well.
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <serge@hallyn.com>
      Acked-by: Christian Brauner's avatarChristian Brauner <christian@brauner.io>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      b1d749c5
  3. 16 May, 2018 1 commit
  4. 14 May, 2018 5 commits
  5. 13 May, 2018 1 commit
    • Al Viro's avatar
      fix breakage caused by d_find_alias() semantics change · b127125d
      Al Viro authored
      "VFS: don't keep disconnected dentries on d_anon" had a non-trivial
      side-effect - d_unhashed() now returns true for those dentries,
      making d_find_alias() skip them altogether.  For most of its callers
      that's fine - we really want a connected alias there.  However,
      there is a codepath where we relied upon picking such aliases
      if nothing else could be found - selinux delayed initialization
      of contexts for inodes on already mounted filesystems used to
      rely upon that.
      
      Cc: stable@kernel.org # f1ee6162 "VFS: don't keep disconnected dentries on d_anon"
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b127125d
  6. 11 May, 2018 3 commits
    • Tycho Andersen's avatar
      dh key: get rid of stack allocated array for zeroes · 890e2abe
      Tycho Andersen authored
      We're interested in getting rid of all of the stack allocated arrays in
      the kernel: https://lkml.org/lkml/2018/3/7/621
      
      This case is interesting, since we really just need an array of bytes that
      are zero. The loop already ensures that if the array isn't exactly the
      right size that enough zero bytes will be copied in. So, instead of
      choosing this value to be the size of the hash, let's just choose it to be
      32, since that is a common size, is not too big, and will not result in too
      many extra iterations of the loop.
      
      v2: split out from other patch, just hardcode array size instead of
          dynamically allocating something the right size
      v3: fix typo of 256 -> 32
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      CC: David Howells <dhowells@redhat.com>
      CC: James Morris <jmorris@namei.org>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      CC: Eric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarJames Morris <james.morris@microsoft.com>
      890e2abe
    • Tycho Andersen's avatar
      dh key: get rid of stack allocated array · 383203ef
      Tycho Andersen authored
      We're interested in getting rid of all of the stack allocated arrays in the
      kernel: https://lkml.org/lkml/2018/3/7/621
      
      This particular vla is used as a temporary output buffer in case there is
      too much hash output for the destination buffer. Instead, let's just
      allocate a buffer that's big enough initially, but only copy back to
      userspace the amount that was originally asked for.
      
      v2: allocate enough in the original output buffer vs creating a temporary
          output buffer
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      CC: David Howells <dhowells@redhat.com>
      CC: James Morris <jmorris@namei.org>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      CC: Eric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarJames Morris <james.morris@microsoft.com>
      383203ef
    • Tycho Andersen's avatar
      big key: get rid of stack array allocation · a964f395
      Tycho Andersen authored
      We're interested in getting rid of all of the stack allocated arrays in the
      kernel [1]. This patch simply hardcodes the iv length to match that of the
      hardcoded cipher.
      
      [1]: https://lkml.org/lkml/2018/3/7/621
      
      v2: hardcode the length of the nonce to be the GCM AES IV length, and do a
          sanity check in init(), Eric Biggers
      v3: * remember to free big_key_aead when sanity check fails
          * define a constant for big key IV size so it can be changed along side
            the algorithm in the code
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      CC: David Howells <dhowells@redhat.com>
      CC: James Morris <jmorris@namei.org>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      CC: Jason A. Donenfeld <Jason@zx2c4.com>
      CC: Eric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarJames Morris <james.morris@microsoft.com>
      a964f395
  7. 04 May, 2018 3 commits
  8. 03 May, 2018 2 commits
  9. 17 Apr, 2018 2 commits
    • Richard Guy Briggs's avatar
      audit: normalize MAC_POLICY_LOAD record · d141136f
      Richard Guy Briggs authored
      The audit MAC_POLICY_LOAD record had redundant dangling keywords and was
      missing information about which LSM was responsible and its completion
      status.  While this record is only issued on success, the parser expects
      the res= field to be present.
      
      Old record:
      type=MAC_POLICY_LOAD msg=audit(1479299795.404:43): policy loaded auid=0 ses=1
      
      Delete the redundant dangling keywords, add the lsm= field and the res=
      field.
      
      New record:
      type=MAC_POLICY_LOAD msg=audit(1523293846.204:894): auid=0 ses=1 lsm=selinux res=1
      
      See: https://github.com/linux-audit/audit-kernel/issues/47Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      d141136f
    • Richard Guy Briggs's avatar
      audit: normalize MAC_STATUS record · 4195ed42
      Richard Guy Briggs authored
      There were two formats of the audit MAC_STATUS record, one of which was more
      standard than the other.  One listed enforcing status changes and the
      other listed enabled status changes with a non-standard label.  In
      addition, the record was missing information about which LSM was
      responsible and the operation's completion status.  While this record is
      only issued on success, the parser expects the res= field to be present.
      
      old enforcing/permissive:
      type=MAC_STATUS msg=audit(1523312831.378:24514): enforcing=0 old_enforcing=1 auid=0 ses=1
      old enable/disable:
      type=MAC_STATUS msg=audit(1523312831.378:24514): selinux=0 auid=0 ses=1
      
      List both sets of status and old values and add the lsm= field and the
      res= field.
      
      Here is the new format:
      type=MAC_STATUS msg=audit(1523293828.657:891): enforcing=0 old_enforcing=1 auid=0 ses=1 enabled=1 old-enabled=1 lsm=selinux res=1
      
      This record already accompanied a SYSCALL record.
      
      See: https://github.com/linux-audit/audit-kernel/issues/46Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      [PM: 80-char fixes, merge fuzz, use new SELinux state functions]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      4195ed42
  10. 16 Apr, 2018 1 commit
  11. 11 Apr, 2018 4 commits
    • Davidlohr Bueso's avatar
      ipc/msg: introduce msgctl(MSG_STAT_ANY) · 23c8cec8
      Davidlohr Bueso authored
      There is a permission discrepancy when consulting msq ipc object
      metadata between /proc/sysvipc/msg (0444) and the MSG_STAT shmctl
      command.  The later does permission checks for the object vs S_IRUGO.
      As such there can be cases where EACCESS is returned via syscall but the
      info is displayed anyways in the procfs files.
      
      While this might have security implications via info leaking (albeit no
      writing to the msq metadata), this behavior goes way back and showing
      all the objects regardless of the permissions was most likely an
      overlook - so we are stuck with it.  Furthermore, modifying either the
      syscall or the procfs file can cause userspace programs to break (ie
      ipcs).  Some applications require getting the procfs info (without root
      privileges) and can be rather slow in comparison with a syscall -- up to
      500x in some reported cases for shm.
      
      This patch introduces a new MSG_STAT_ANY command such that the msq ipc
      object permissions are ignored, and only audited instead.  In addition,
      I've left the lsm security hook checks in place, as if some policy can
      block the call, then the user has no other choice than just parsing the
      procfs file.
      
      Link: http://lkml.kernel.org/r/20180215162458.10059-4-dave@stgolabs.netSigned-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Reported-by: default avatarRobert Kettler <robert.kettler@outlook.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23c8cec8
    • Davidlohr Bueso's avatar
      ipc/sem: introduce semctl(SEM_STAT_ANY) · a280d6dc
      Davidlohr Bueso authored
      There is a permission discrepancy when consulting shm ipc object
      metadata between /proc/sysvipc/sem (0444) and the SEM_STAT semctl
      command.  The later does permission checks for the object vs S_IRUGO.
      As such there can be cases where EACCESS is returned via syscall but the
      info is displayed anyways in the procfs files.
      
      While this might have security implications via info leaking (albeit no
      writing to the sma metadata), this behavior goes way back and showing
      all the objects regardless of the permissions was most likely an
      overlook - so we are stuck with it.  Furthermore, modifying either the
      syscall or the procfs file can cause userspace programs to break (ie
      ipcs).  Some applications require getting the procfs info (without root
      privileges) and can be rather slow in comparison with a syscall -- up to
      500x in some reported cases for shm.
      
      This patch introduces a new SEM_STAT_ANY command such that the sem ipc
      object permissions are ignored, and only audited instead.  In addition,
      I've left the lsm security hook checks in place, as if some policy can
      block the call, then the user has no other choice than just parsing the
      procfs file.
      
      Link: http://lkml.kernel.org/r/20180215162458.10059-3-dave@stgolabs.netSigned-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Reported-by: default avatarRobert Kettler <robert.kettler@outlook.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a280d6dc
    • Davidlohr Bueso's avatar
      ipc/shm: introduce shmctl(SHM_STAT_ANY) · c21a6970
      Davidlohr Bueso authored
      Patch series "sysvipc: introduce STAT_ANY commands", v2.
      
      The following patches adds the discussed (see [1]) new command for shm
      as well as for sems and msq as they are subject to the same
      discrepancies for ipc object permission checks between the syscall and
      via procfs.  These new commands are justified in that (1) we are stuck
      with this semantics as changing syscall and procfs can break userland;
      and (2) some users can benefit from performance (for large amounts of
      shm segments, for example) from not having to parse the procfs
      interface.
      
      Once merged, I will submit the necesary manpage updates.  But I'm thinking
      something like:
      
      : diff --git a/man2/shmctl.2 b/man2/shmctl.2
      : index 7bb503999941..bb00bbe21a57 100644
      : --- a/man2/shmctl.2
      : +++ b/man2/shmctl.2
      : @@ -41,6 +41,7 @@
      :  .\" 2005-04-25, mtk -- noted aberrant Linux behavior w.r.t. new
      :  .\"	attaches to a segment that has already been marked for deletion.
      :  .\" 2005-08-02, mtk: Added IPC_INFO, SHM_INFO, SHM_STAT descriptions.
      : +.\" 2018-02-13, dbueso: Added SHM_STAT_ANY description.
      :  .\"
      :  .TH SHMCTL 2 2017-09-15 "Linux" "Linux Programmer's Manual"
      :  .SH NAME
      : @@ -242,6 +243,18 @@ However, the
      :  argument is not a segment identifier, but instead an index into
      :  the kernel's internal array that maintains information about
      :  all shared memory segments on the system.
      : +.TP
      : +.BR SHM_STAT_ANY " (Linux-specific)"
      : +Return a
      : +.I shmid_ds
      : +structure as for
      : +.BR SHM_STAT .
      : +However, the
      : +.I shm_perm.mode
      : +is not checked for read access for
      : +.IR shmid ,
      : +resembing the behaviour of
      : +/proc/sysvipc/shm.
      :  .PP
      :  The caller can prevent or allow swapping of a shared
      :  memory segment with the following \fIcmd\fP values:
      : @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in the
      :  kernel's internal array recording information about all
      :  shared memory segments.
      :  (This information can be used with repeated
      : -.B SHM_STAT
      : +.B SHM_STAT/SHM_STAT_ANY
      :  operations to obtain information about all shared memory segments
      :  on the system.)
      :  A successful
      : @@ -328,7 +341,7 @@ isn't accessible.
      :  \fIshmid\fP is not a valid identifier, or \fIcmd\fP
      :  is not a valid command.
      :  Or: for a
      : -.B SHM_STAT
      : +.B SHM_STAT/SHM_STAT_ANY
      :  operation, the index value specified in
      :  .I shmid
      :  referred to an array slot that is currently unused.
      
      This patch (of 3):
      
      There is a permission discrepancy when consulting shm ipc object metadata
      between /proc/sysvipc/shm (0444) and the SHM_STAT shmctl command.  The
      later does permission checks for the object vs S_IRUGO.  As such there can
      be cases where EACCESS is returned via syscall but the info is displayed
      anyways in the procfs files.
      
      While this might have security implications via info leaking (albeit no
      writing to the shm metadata), this behavior goes way back and showing all
      the objects regardless of the permissions was most likely an overlook - so
      we are stuck with it.  Furthermore, modifying either the syscall or the
      procfs file can cause userspace programs to break (ie ipcs).  Some
      applications require getting the procfs info (without root privileges) and
      can be rather slow in comparison with a syscall -- up to 500x in some
      reported cases.
      
      This patch introduces a new SHM_STAT_ANY command such that the shm ipc
      object permissions are ignored, and only audited instead.  In addition,
      I've left the lsm security hook checks in place, as if some policy can
      block the call, then the user has no other choice than just parsing the
      procfs file.
      
      [1] https://lkml.org/lkml/2017/12/19/220
      
      Link: http://lkml.kernel.org/r/20180215162458.10059-2-dave@stgolabs.netSigned-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Robert Kettler <robert.kettler@outlook.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c21a6970
    • Tetsuo Handa's avatar
      commoncap: Handle memory allocation failure. · 1f578172
      Tetsuo Handa authored
      syzbot is reporting NULL pointer dereference at xattr_getsecurity() [1],
      for cap_inode_getsecurity() is returning sizeof(struct vfs_cap_data) when
      memory allocation failed. Return -ENOMEM if memory allocation failed.
      
      [1] https://syzkaller.appspot.com/bug?id=a55ba438506fe68649a5f50d2d82d56b365e0107Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities")
      Reported-by: default avatarsyzbot <syzbot+9369930ca44f29e60e2d@syzkaller.appspotmail.com>
      Cc: stable <stable@vger.kernel.org> # 4.14+
      Acked-by: Serge Hallyn's avatarSerge E. Hallyn <serge@hallyn.com>
      Acked-by: default avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      1f578172
  12. 09 Apr, 2018 1 commit
  13. 06 Apr, 2018 2 commits
  14. 31 Mar, 2018 2 commits
  15. 29 Mar, 2018 2 commits
    • Kirill Tkhai's avatar
      security: Remove rtnl_lock() in selinux_xfrm_notify_policyload() · 350311aa
      Kirill Tkhai authored
      rt_genid_bump_all() consists of ipv4 and ipv6 part.
      ipv4 part is incrementing of net::ipv4::rt_genid,
      and I see many places, where it's read without rtnl_lock().
      
      ipv6 part calls __fib6_clean_all(), and it's also
      called without rtnl_lock() in other places.
      
      So, rtnl_lock() here was used to iterate net_namespace_list only,
      and we can remove it.
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      350311aa
    • Kirill Tkhai's avatar
      net: Introduce net_rwsem to protect net_namespace_list · f0b07bb1
      Kirill Tkhai authored
      rtnl_lock() is used everywhere, and contention is very high.
      When someone wants to iterate over alive net namespaces,
      he/she has no a possibility to do that without exclusive lock.
      But the exclusive rtnl_lock() in such places is overkill,
      and it just increases the contention. Yes, there is already
      for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
      and this can't be sleepable. Also, sometimes it may be need
      really prevent net_namespace_list growth, so for_each_net_rcu()
      is not fit there.
      
      This patch introduces new rw_semaphore, which will be used
      instead of rtnl_mutex to protect net_namespace_list. It is
      sleepable and allows not-exclusive iterations over net
      namespaces list. It allows to stop using rtnl_lock()
      in several places (what is made in next patches) and makes
      less the time, we keep rtnl_mutex. Here we just add new lock,
      while the explanation of we can remove rtnl_lock() there are
      in next patches.
      
      Fine grained locks generally are better, then one big lock,
      so let's do that with net_namespace_list, while the situation
      allows that.
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0b07bb1
  16. 28 Mar, 2018 1 commit
  17. 27 Mar, 2018 2 commits
  18. 25 Mar, 2018 6 commits
    • Petr Vorel's avatar
      ima: Fallback to the builtin hash algorithm · ab60368a
      Petr Vorel authored
      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: default avatarPetr Vorel <pvorel@suse.cz>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      ab60368a
    • Martin Townsend's avatar
      ima: Add smackfs to the default appraise/measure list · 1c070b18
      Martin Townsend authored
      This is required to use SMACK and IMA/EVM together. Add it to the
      default nomeasure/noappraise list like other pseudo filesystems.
      Signed-off-by: default avatarMartin Townsend <mtownsend1973@gmail.com>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      1c070b18
    • Sascha Hauer's avatar
      evm: check for remount ro in progress before writing · 70946c4a
      Sascha Hauer authored
      EVM might update the evm xattr while the VFS performs a remount to
      readonly mode. This is not properly checked for, additionally check
      the s_readonly_remount superblock flag before writing.
      
      The bug can for example be observed with UBIFS. UBIFS checks the free
      space on the device before and after a remount. With EVM enabled the
      free space sometimes differs between both checks.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      70946c4a
    • Thiago Jung Bauermann's avatar
      ima: Improvements in ima_appraise_measurement() · f5e51fa3
      Thiago Jung Bauermann authored
      Replace nested ifs in the EVM xattr verification logic with a switch
      statement, making the code easier to understand.
      
      Also, add comments to the if statements in the out section and constify the
      cause variable.
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <serge@hallyn.com>
      f5e51fa3
    • Thiago Jung Bauermann's avatar
      ima: Simplify ima_eventsig_init() · 1775cb87
      Thiago Jung Bauermann authored
      The "goto out" statement doesn't have any purpose since there's no cleanup
      to be done when returning early, so remove it. This also makes the rc
      variable unnecessary so remove it as well.
      
      Also, the xattr_len and fmt variables are redundant so remove them as well.
      Signed-off-by: default avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <serge@hallyn.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      1775cb87
    • Thiago Jung Bauermann's avatar
      integrity: Remove unused macro IMA_ACTION_RULE_FLAGS · 11c60f23
      Thiago Jung Bauermann authored
      This macro isn't used anymore since commit 0d73a552 ("ima: re-introduce
      own integrity cache lock"), so remove it.
      Signed-off-by: default avatarThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Acked-by: Serge Hallyn's avatarSerge Hallyn <serge@hallyn.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      11c60f23