1. 01 Dec, 2018 6 commits
    • Mimi Zohar's avatar
      ima: re-initialize iint->atomic_flags · 1f898348
      Mimi Zohar authored
      commit e2598077 upstream.
      Intermittently security.ima is not being written for new files.  This
      patch re-initializes the new slab iint->atomic_flags field before
      freeing it.
      Fixes: commit 0d73a552
       ("ima: re-introduce own integrity cache lock")
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dmitry Kasatkin's avatar
      ima: re-introduce own integrity cache lock · 166f4542
      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
      * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called
        and extended attributes have changed. On file open, it causes IMA to
        clear iint->flags IMA_DONE_MASK to re-appraise.
      * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
        It is cleared if file policy changes and no update is needed.
      * IMA_DIGSIG - indicates that file security.ima has signature and file
        security.ima must not update to file has on file close.
      * IMA_MUST_MEASURE - indicates the file is in the measurement policy.
      Fixes: Commit 65523218
       ("xfs: remove i_iolock and use i_rwsem in
      the VFS inode instead")
      Signed-off-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Matthew Garrett's avatar
      EVM: Add support for portable signature format · 87043e4c
      Matthew Garrett authored
      commit 50b97748
      The EVM signature includes the inode number and (optionally) the
      filesystem UUID, making it impractical to ship EVM signatures in
      packages. This patch adds a new portable format intended to allow
      distributions to include EVM signatures. It is identical to the existing
      format but hardcodes the inode and generation numbers to 0 and does not
      include the filesystem UUID even if the kernel is configured to do so.
      Removing the inode means that the metadata and signature from one file
      could be copied to another file without invalidating it. This is avoided
      by ensuring that an IMA xattr is present during EVM validation.
      Portable signatures are intended to be immutable - ie, they will never
      be transformed into HMACs.
      Based on earlier work by Dmitry Kasatkin and Mikhail Kurinnoi.
      Signed-off-by: default avatarMatthew Garrett <mjg59@google.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mimi Zohar's avatar
      ima: always measure and audit files in policy · 5f9fb1a0
      Mimi Zohar authored
      commit f3cc6b25
      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.
      In general, adding, deleting or in anyway changing which files are
      included in the IMA measurement list is not a good idea, as it might
      result in not being able to unseal trusted keys sealed to a specific
      TPM PCR value.  This patch not only adds file measurements that were
      not previously measured, but specifies that the file hash value for
      these files will be 0's.
      As the IMA measurement list ordering is not consistent from one boot
      to the next, it is unlikely that anyone is sealing keys based on the
      IMA measurement list.  Remote attestation servers should be able to
      process these new measurement records, but might complain about
      these unknown records.
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Eric W. Biederman's avatar
      Revert "evm: Translate user/group ids relative to s_user_ns when computing HMAC" · 5fed1ff8
      Eric W. Biederman authored
      commit 19339c25 upstream.
      This reverts commit 0b3c9761.
      Seth Forshee <seth.forshee@canonical.com> writes:
      > All right, I think 0b3c9761
       should be
      > reverted then. EVM is a machine-local integrity mechanism, and so it
      > makes sense that the signature would be based on the kernel's notion of
      > the uid and not the filesystem's.
      I added a commment explaining why the EVM hmac needs to be in the
      kernel's notion of uid and gid, not the filesystems to prevent
      remounting the filesystem and gaining unwaranted trust in files.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Aditya Kali <adityakali@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tetsuo Handa's avatar
      selinux: Add __GFP_NOWARN to allocation at str_read() · 47ff7629
      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=7f2f5aad79ea8663c296a2eedb81978401a908f0
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: default avatarsyzbot <syzbot+ac488b9811036cea7ea0@syzkaller.appspotmail.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 13 Nov, 2018 1 commit
  3. 26 Sep, 2018 2 commits
  4. 19 Sep, 2018 1 commit
  5. 24 Aug, 2018 1 commit
  6. 03 Aug, 2018 1 commit
  7. 06 Jun, 2018 2 commits
    • Sachin Grover's avatar
      selinux: KASAN: slab-out-of-bounds in xattr_getsecurity · c738c806
      Sachin Grover authored
      commit efe3de79e0b52ca281ef6691480c8c68c82a4657 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: default avatarSachin Grover <sgrover@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mimi Zohar's avatar
      Revert "ima: limit file hash setting by user to fix and log modes" · 28fffa90
      Mimi Zohar authored
      commit f5acb3dc upstream.
      Userspace applications have been modified to write security xattrs,
      but they are not context aware.  In the case of security.ima, the
      security xattr can be either a file hash or a file signature.
      Permitting writing one, but not the other requires the application to
      be context aware.
      In addition, userspace applications might write files to a staging
      area, which might not be in policy, and then change some file metadata
      (eg. owner) making it in policy.  As a result, these files are not
      labeled properly.
      This reverts commit c68ed80c
      , which
      prevents writing file hashes as security.ima xattrs.
      Requested-by: default avatarPatrick Ohly <patrick.ohly@intel.com>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 30 May, 2018 2 commits
    • Petr Vorel's avatar
      ima: Fallback to the builtin hash algorithm · 99d8240f
      Petr Vorel authored
      [ Upstream commit ab60368ab6a452466885ef4edf0cefd089465132 ]
      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
      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
      [    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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Randy Dunlap's avatar
      integrity/security: fix digsig.c build error with header file · 8a5a436a
      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: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default 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: default avatarJames Morris <james.morris@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 13 Apr, 2018 1 commit
  10. 08 Apr, 2018 2 commits
  11. 22 Mar, 2018 3 commits
    • Mimi Zohar's avatar
      ima: relax requiring a file signature for new files with zero length · 27a0856c
      Mimi Zohar authored
      [ Upstream commit b7e27bc1 ]
      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: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • John Johansen's avatar
      apparmor: Make path_max parameter readonly · d55a55bc
      John Johansen authored
      [ Upstream commit 622f6e32
      The path_max parameter determines the max size of buffers allocated
      but it should  not be setable at run time. If can be used to cause an
      root@ubuntu:~# echo 16777216 > /sys/module/apparmor/parameters/path_max
      root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max
      [  122.141911] BUG: unable to handle kernel paging request at ffff880080945fff
      [  122.143497] IP: [<ffffffff81228844>] d_absolute_path+0x44/0xa0
      [  122.144742] PGD 220c067 PUD 0
      [  122.145453] Oops: 0002 [#1] SMP
      [  122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect
      [  122.163365]  ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes
      [  122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu
      [  122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
      [  122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000
      [  122.170018] RIP: 0010:[<ffffffff81228844>]  [<ffffffff81228844>] d_absolute_path+0x44/0xa0
      [  122.171525] RSP: 0018:ffff880076477b90  EFLAGS: 00010206
      [  122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000
      [  122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010
      [  122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000
      [  122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000
      [  122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400
      [  122.178745] FS:  00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000
      [  122.180176] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0
      [  122.182469] Stack:
      [  122.182843]  00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000
      [  122.184409]  00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58
      [  122.185810]  0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000
      [  122.187231] Call Trace:
      [  122.187680]  [<ffffffff81385671>] aa_path_name+0x81/0x370
      [  122.188637]  [<ffffffff813875dd>] profile_transition+0xbd/0xb80
      [  122.190181]  [<ffffffff811af9bc>] ? zone_statistics+0x7c/0xa0
      [  122.191674]  [<ffffffff81389b20>] apparmor_bprm_set_creds+0x9b0/0xac0
      [  122.193288]  [<ffffffff812e1971>] ? ext4_xattr_get+0x81/0x220
      [  122.194793]  [<ffffffff812e800c>] ? ext4_xattr_security_get+0x1c/0x30
      [  122.196392]  [<ffffffff813449b9>] ? get_vfs_caps_from_disk+0x69/0x110
      [  122.198004]  [<ffffffff81232d4f>] ? mnt_may_suid+0x3f/0x50
      [  122.199737]  [<ffffffff81344b03>] ? cap_bprm_set_creds+0xa3/0x600
      [  122.201377]  [<ffffffff81346e53>] security_bprm_set_creds+0x33/0x50
      [  122.203024]  [<ffffffff81214ce5>] prepare_binprm+0x85/0x190
      [  122.204515]  [<ffffffff81216545>] do_execveat_common.isra.33+0x485/0x710
      [  122.206200]  [<ffffffff81216a6a>] SyS_execve+0x3a/0x50
      [  122.207615]  [<ffffffff81838795>] stub_execve+0x5/0x5
      [  122.208978]  [<ffffffff818384f2>] ? entry_SYSCALL_64_fastpath+0x16/0x71
      [  122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff <c6> 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8
      [  122.217320] RIP  [<ffffffff81228844>] d_absolute_path+0x44/0xa0
      [  122.218860]  RSP <ffff880076477b90>
      [  122.219919] CR2: ffff880080945fff
      [  122.220936] ---[ end trace 506cdbd85eb6c55e ]---
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alexander Potapenko's avatar
      selinux: check for address length in selinux_socket_bind() · b243aa88
      Alexander Potapenko authored
      [ Upstream commit e2f586bd
      KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
      uninitialized memory in selinux_socket_bind():
      BUG: KMSAN: use of unitialized memory
      inter: 0
      CPU: 3 PID: 1074 Comm: packet2 Tainted: G    B           4.8.0-rc6+ #1916
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48
       ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550
       0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff825759c8>] dump_stack+0x238/0x290 lib/dump_stack.c:51
       [<ffffffff818bdee6>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
       [<ffffffff818bf0fb>] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
       [<ffffffff822dae71>] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288
       [<ffffffff8229357c>] security_socket_bind+0x1ec/0x240 security/security.c:1240
       [<ffffffff84265d98>] SYSC_bind+0x358/0x5f0 net/socket.c:1366
       [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
       [<ffffffff8518217c>] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?
      chained origin: 00000000ba6009bb
       [<ffffffff810bb7a7>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
       [<     inline     >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
       [<     inline     >] kmsan_save_stack mm/kmsan/kmsan.c:337
       [<ffffffff818bd2b8>] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530
       [<ffffffff818bf033>] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380
       [<ffffffff84265b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356
       [<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
       [<ffffffff8518217c>] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?
      origin description: ----address@SYSC_bind (origin=00000000b8c00900)
      (the line numbers are relative to 4.8-rc6, but the bug persists upstream)
      , when I run the following program as root:
        #include <string.h>
        #include <sys/socket.h>
        #include <netinet/in.h>
        int main(int argc, char *argv[]) {
          struct sockaddr addr;
          int size = 0;
          if (argc > 1) {
            size = atoi(argv[1]);
          memset(&addr, 0, sizeof(addr));
          int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
          bind(fd, &addr, size);
          return 0;
      (for different values of |size| other error reports are printed).
      This happens because bind() unconditionally copies |size| bytes of
      |addr| to the kernel, leaving the rest uninitialized. Then
      security_socket_bind() reads the IP address bytes, including the
      uninitialized ones, to determine the port, or e.g. pass them further to
      sel_netnode_find(), which uses them to calculate a hash.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      [PM: fixed some whitespace damage]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 25 Feb, 2018 3 commits
  13. 13 Feb, 2018 1 commit
  14. 05 Jan, 2018 6 commits
  15. 14 Dec, 2017 1 commit
    • Eric Biggers's avatar
      KEYS: add missing permission check for request_key() destination · 982707eb
      Eric Biggers authored
      commit 4dca6ea1 upstream.
      When the request_key() syscall is not passed a destination keyring, it
      links the requested key (if constructed) into the "default" request-key
      keyring.  This should require Write permission to the keyring.  However,
      there is actually no permission check.
      This can be abused to add keys to any keyring to which only Search
      permission is granted.  This is because Search permission allows joining
      the keyring.  keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
      then will set the default request-key keyring to the session keyring.
      Then, request_key() can be used to add keys to the keyring.
      Both negatively and positively instantiated keys can be added using this
      method.  Adding negative keys is trivial.  Adding a positive key is a
      bit trickier.  It requires that either /sbin/request-key positively
      instantiates the key, or that another thread adds the key to the process
      keyring at just the right time, such that request_key() misses it
      initially but then finds it in construct_alloc_key().
      Fix this bug by checking for Write permission to the keyring in
      construct_get_dest_keyring() when the default keyring is being used.
      We don't do the permission check for non-default keyrings because that
      was already done by the earlier call to lookup_user_key().  Also,
      request_key_and_link() is currently passed a 'struct key *' rather than
      a key_ref_t, so the "possessed" bit is unavailable.
      We also don't do the permission check for the "requestor keyring", to
      continue to support the use case described by commit 8bbf4976
      ("KEYS: Alter use of key instantiation link-to-keyring argument") where
      /sbin/request-key recursively calls request_key() to add keys to the
      original requestor's destination keyring.  (I don't know of any users
      who actually do that, though...)
      Fixes: 3e30148c
       ("[PATCH] Keys: Make request-key create an authorisation key")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. 09 Dec, 2017 1 commit
  17. 24 Nov, 2017 1 commit
  18. 18 Nov, 2017 1 commit
  19. 15 Nov, 2017 3 commits
  20. 08 Nov, 2017 1 commit