1. 27 Nov, 2017 2 commits
    • John Johansen's avatar
      apparmor: fix oops in audit_signal_cb hook · b12cbb21
      John Johansen authored
      The apparmor_audit_data struct ordering got messed up during a merge
      conflict, resulting in the signal integer and peer pointer being in
      a union instead of a struct.
      
      For most of the 4.13 and 4.14 life cycle, this was hidden by
      commit 651e28c5 ("apparmor: add base infastructure for socket
      mediation") which fixed the apparmor_audit_data struct when its data
      was added. When that commit was reverted in -rc7 the signal audit bug
      was exposed, and unfortunately it never showed up in any of the
      testing until after 4.14 was released. Shaun Khan, Zephaniah
      E. Loss-Cutler-Hull filed nearly simultaneous bug reports (with
      different oopes, the smaller of which is included below).
      
      Full credit goes to Tetsuo Handa for jumping on this as well and
      noticing the audit data struct problem and reporting it.
      
      [   76.178568] BUG: unable to handle kernel paging request at
      ffffffff0eee3bc0
      [   76.178579] IP: audit_signal_cb+0x6c/0xe0
      [   76.178581] PGD 1a640a067 P4D 1a640a067 PUD 0
      [   76.178586] Oops: 0000 [#1] PREEMPT SMP
      [   76.178589] Modules linked in: fuse rfcomm bnep usblp uvcvideo btusb
      btrtl btbcm btintel bluetooth ecdh_generic ip6table_filter ip6_tables
      xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
      iptable_filter ip_tables x_tables intel_rapl joydev wmi_bmof serio_raw
      iwldvm iwlwifi shpchp kvm_intel kvm irqbypass autofs4 algif_skcipher
      nls_iso8859_1 nls_cp437 crc32_pclmul ghash_clmulni_intel
      [   76.178620] CPU: 0 PID: 10675 Comm: pidgin Not tainted
      4.14.0-f1-dirty #135
      [   76.178623] Hardware name: Hewlett-Packard HP EliteBook Folio
      9470m/18DF, BIOS 68IBD Ver. F.62 10/22/2015
      [   76.178625] task: ffff9c7a94c31dc0 task.stack: ffffa09b02a4c000
      [   76.178628] RIP: 0010:audit_signal_cb+0x6c/0xe0
      [   76.178631] RSP: 0018:ffffa09b02a4fc08 EFLAGS: 00010292
      [   76.178634] RAX: ffffa09b02a4fd60 RBX: ffff9c7aee0741f8 RCX:
      0000000000000000
      [   76.178636] RDX: ffffffffee012290 RSI: 0000000000000006 RDI:
      ffff9c7a9493d800
      [   76.178638] RBP: ffffa09b02a4fd40 R08: 000000000000004d R09:
      ffffa09b02a4fc46
      [   76.178641] R10: ffffa09b02a4fcb8 R11: ffff9c7ab44f5072 R12:
      ffffa09b02a4fd40
      [   76.178643] R13: ffffffff9e447be0 R14: ffff9c7a94c31dc0 R15:
      0000000000000001
      [   76.178646] FS:  00007f8b11ba2a80(0000) GS:ffff9c7afea00000(0000)
      knlGS:0000000000000000
      [   76.178648] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   76.178650] CR2: ffffffff0eee3bc0 CR3: 00000003d5209002 CR4:
      00000000001606f0
      [   76.178652] Call Trace:
      [   76.178660]  common_lsm_audit+0x1da/0x780
      [   76.178665]  ? d_absolute_path+0x60/0x90
      [   76.178669]  ? aa_check_perms+0xcd/0xe0
      [   76.178672]  aa_check_perms+0xcd/0xe0
      [   76.178675]  profile_signal_perm.part.0+0x90/0xa0
      [   76.178679]  aa_may_signal+0x16e/0x1b0
      [   76.178686]  apparmor_task_kill+0x51/0x120
      [   76.178690]  security_task_kill+0x44/0x60
      [   76.178695]  group_send_sig_info+0x25/0x60
      [   76.178699]  kill_pid_info+0x36/0x60
      [   76.178703]  SYSC_kill+0xdb/0x180
      [   76.178707]  ? preempt_count_sub+0x92/0xd0
      [   76.178712]  ? _raw_write_unlock_irq+0x13/0x30
      [   76.178716]  ? task_work_run+0x6a/0x90
      [   76.178720]  ? exit_to_usermode_loop+0x80/0xa0
      [   76.178723]  entry_SYSCALL_64_fastpath+0x13/0x94
      [   76.178727] RIP: 0033:0x7f8b0e58b767
      [   76.178729] RSP: 002b:00007fff19efd4d8 EFLAGS: 00000206 ORIG_RAX:
      000000000000003e
      [   76.178732] RAX: ffffffffffffffda RBX: 0000557f3e3c2050 RCX:
      00007f8b0e58b767
      [   76.178735] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
      000000000000263b
      [   76.178737] RBP: 0000000000000000 R08: 0000557f3e3c2270 R09:
      0000000000000001
      [   76.178739] R10: 000000000000022d R11: 0000000000000206 R12:
      0000000000000000
      [   76.178741] R13: 0000000000000001 R14: 0000557f3e3c13c0 R15:
      0000000000000000
      [   76.178745] Code: 48 8b 55 18 48 89 df 41 b8 20 00 08 01 5b 5d 48 8b
      42 10 48 8b 52 30 48 63 48 4c 48 8b 44 c8 48 31 c9 48 8b 70 38 e9 f4 fd
      00 00 <48> 8b 14 d5 40 27 e5 9e 48 c7 c6 7d 07 19 9f 48 89 df e8 fd 35
      [   76.178794] RIP: audit_signal_cb+0x6c/0xe0 RSP: ffffa09b02a4fc08
      [   76.178796] CR2: ffffffff0eee3bc0
      [   76.178799] ---[ end trace 514af9529297f1a3 ]---
      
      Fixes: cd1dbf76 ("apparmor: add the ability to mediate signals")
      Reported-by: default avatarZephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
      Reported-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Suggested-by: default avatarTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Tested-by: default avatarIvan Kozik <ivan@ludios.org>
      Tested-by: default avatarZephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
      Tested-by: default avatarChristian Boltz <apparmor@cboltz.de>
      Tested-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      b12cbb21
    • Linus Torvalds's avatar
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds authored
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      
      The script to do this was:
      
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
          SYMS="RDONLY NOSUID NODEV NOEXEC SYNCHRONOUS REMOUNT MANDLOCK \
                DIRSYNC NOATIME NODIRATIME BIND MOVE REC VERBOSE SILENT \
                POSIXACL UNBINDABLE PRIVATE SLAVE SHARED RELATIME KERNMOUNT \
                I_VERSION STRICTATIME LAZYTIME SUBMOUNT NOREMOTELOCK NOSEC BORN \
                ACTIVE NOUSER"
      
          SED_PROG=
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
      
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
      
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1751e8a6
  2. 21 Nov, 2017 10 commits
    • Kees Cook's avatar
      treewide: Switch DEFINE_TIMER callbacks to struct timer_list * · 24ed960a
      Kees Cook authored
      This changes all DEFINE_TIMER() callbacks to use a struct timer_list
      pointer instead of unsigned long. Since the data argument has already been
      removed, none of these callbacks are using their argument currently, so
      this renames the argument to "unused".
      
      Done using the following semantic patch:
      
      @match_define_timer@
      declarer name DEFINE_TIMER;
      identifier _timer, _callback;
      @@
      
       DEFINE_TIMER(_timer, _callback);
      
      @change_callback depends on match_define_timer@
      identifier match_define_timer._callback;
      type _origtype;
      identifier _origarg;
      @@
      
       void
      -_callback(_origtype _origarg)
      +_callback(struct timer_list *unused)
       { ... }
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      24ed960a
    • John Johansen's avatar
      apparmor: fix possible recursive lock warning in __aa_create_ns · feb3c766
      John Johansen authored
      Use mutex_lock_nested to provide lockdep the parent child lock ordering of
      the tree.
      
      This fixes the lockdep Warning
      [  305.275177] ============================================
      [  305.275178] WARNING: possible recursive locking detected
      [  305.275179] 4.14.0-rc7+ #320 Not tainted
      [  305.275180] --------------------------------------------
      [  305.275181] apparmor_parser/1339 is trying to acquire lock:
      [  305.275182]  (&ns->lock){+.+.}, at: [<ffffffff970544dd>] __aa_create_ns+0x6d/0x1e0
      [  305.275187]
                     but task is already holding lock:
      [  305.275187]  (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
      [  305.275190]
                     other info that might help us debug this:
      [  305.275191]  Possible unsafe locking scenario:
      
      [  305.275192]        CPU0
      [  305.275193]        ----
      [  305.275193]   lock(&ns->lock);
      [  305.275194]   lock(&ns->lock);
      [  305.275195]
                      *** DEADLOCK ***
      
      [  305.275196]  May be due to missing lock nesting notation
      
      [  305.275198] 2 locks held by apparmor_parser/1339:
      [  305.275198]  #0:  (sb_writers#10){.+.+}, at: [<ffffffff96e9c6b7>] vfs_write+0x1a7/0x1d0
      [  305.275202]  #1:  (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
      [  305.275205]
                     stack backtrace:
      [  305.275207] CPU: 1 PID: 1339 Comm: apparmor_parser Not tainted 4.14.0-rc7+ #320
      [  305.275208] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
      [  305.275209] Call Trace:
      [  305.275212]  dump_stack+0x85/0xcb
      [  305.275214]  __lock_acquire+0x141c/0x1460
      [  305.275216]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275218]  ? ___slab_alloc+0x183/0x540
      [  305.275219]  ? ___slab_alloc+0x183/0x540
      [  305.275221]  lock_acquire+0xed/0x1e0
      [  305.275223]  ? lock_acquire+0xed/0x1e0
      [  305.275224]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275227]  __mutex_lock+0x89/0x920
      [  305.275228]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275230]  ? trace_hardirqs_on_caller+0x11f/0x190
      [  305.275231]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275233]  ? __lockdep_init_map+0x57/0x1d0
      [  305.275234]  ? lockdep_init_map+0x9/0x10
      [  305.275236]  ? __rwlock_init+0x32/0x60
      [  305.275238]  mutex_lock_nested+0x1b/0x20
      [  305.275240]  ? mutex_lock_nested+0x1b/0x20
      [  305.275241]  __aa_create_ns+0x6d/0x1e0
      [  305.275243]  aa_prepare_ns+0xc2/0xd0
      [  305.275245]  aa_replace_profiles+0x168/0xf30
      [  305.275247]  ? __might_fault+0x85/0x90
      [  305.275250]  policy_update+0xb9/0x380
      [  305.275252]  profile_load+0x7e/0x90
      [  305.275254]  __vfs_write+0x28/0x150
      [  305.275256]  ? rcu_read_lock_sched_held+0x72/0x80
      [  305.275257]  ? rcu_sync_lockdep_assert+0x2f/0x60
      [  305.275259]  ? __sb_start_write+0xdc/0x1c0
      [  305.275261]  ? vfs_write+0x1a7/0x1d0
      [  305.275262]  vfs_write+0xca/0x1d0
      [  305.275264]  ? trace_hardirqs_on_caller+0x11f/0x190
      [  305.275266]  SyS_write+0x49/0xa0
      [  305.275268]  entry_SYSCALL_64_fastpath+0x23/0xc2
      [  305.275271] RIP: 0033:0x7fa6b22e8c74
      [  305.275272] RSP: 002b:00007ffeaaee6288 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  305.275273] RAX: ffffffffffffffda RBX: 00007ffeaaee62a4 RCX: 00007fa6b22e8c74
      [  305.275274] RDX: 0000000000000a51 RSI: 00005566a8198c10 RDI: 0000000000000004
      [  305.275275] RBP: 0000000000000a39 R08: 0000000000000a51 R09: 0000000000000000
      [  305.275276] R10: 0000000000000000 R11: 0000000000000246 R12: 00005566a8198c10
      [  305.275277] R13: 0000000000000004 R14: 00005566a72ecb88 R15: 00005566a72ec3a8
      
      Fixes: 73688d1e ("apparmor: refactor prepare_ns() and make usable from different views")
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      feb3c766
    • John Johansen's avatar
      apparmor: fix locking when creating a new complain profile. · 5d7c44ef
      John Johansen authored
      Break the per cpu buffer atomic section when creating a new null
      complain profile. In learning mode this won't matter and we can
      safely re-aquire the buffer.
      
      This fixes the following lockdep BUG trace
         nov. 14 14:09:09 cyclope audit[7152]: AVC apparmor="ALLOWED" operation="exec" profile="/usr/sbin/sssd" name="/usr/sbin/adcli" pid=7152 comm="sssd_be" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/usr/sbin/sssd//null-/usr/sbin/adcli"
          nov. 14 14:09:09 cyclope kernel: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
          nov. 14 14:09:09 cyclope kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 7152, name: sssd_be
          nov. 14 14:09:09 cyclope kernel: 1 lock held by sssd_be/7152:
          nov. 14 14:09:09 cyclope kernel:  #0:  (&sig->cred_guard_mutex){....}, at: [<ffffffff8182d53e>] prepare_bprm_creds+0x4e/0x100
          nov. 14 14:09:09 cyclope kernel: CPU: 3 PID: 7152 Comm: sssd_be Not tainted 4.14.0prahal+intel #150
          nov. 14 14:09:09 cyclope kernel: Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET53WW (1.33 ) 09/15/2017
          nov. 14 14:09:09 cyclope kernel: Call Trace:
          nov. 14 14:09:09 cyclope kernel:  dump_stack+0xb0/0x135
          nov. 14 14:09:09 cyclope kernel:  ? _atomic_dec_and_lock+0x15b/0x15b
          nov. 14 14:09:09 cyclope kernel:  ? lockdep_print_held_locks+0xc4/0x130
          nov. 14 14:09:09 cyclope kernel:  ___might_sleep+0x29c/0x320
          nov. 14 14:09:09 cyclope kernel:  ? rq_clock+0xf0/0xf0
          nov. 14 14:09:09 cyclope kernel:  ? __kernel_text_address+0xd/0x40
          nov. 14 14:09:09 cyclope kernel:  __might_sleep+0x95/0x190
          nov. 14 14:09:09 cyclope kernel:  ? aa_new_null_profile+0x50a/0x960
          nov. 14 14:09:09 cyclope kernel:  __mutex_lock+0x13e/0x1a20
          nov. 14 14:09:09 cyclope kernel:  ? aa_new_null_profile+0x50a/0x960
          nov. 14 14:09:09 cyclope kernel:  ? save_stack+0x43/0xd0
          nov. 14 14:09:09 cyclope kernel:  ? kmem_cache_alloc_trace+0x13f/0x290
          nov. 14 14:09:09 cyclope kernel:  ? mutex_lock_io_nested+0x1880/0x1880
          nov. 14 14:09:09 cyclope kernel:  ? profile_transition+0x932/0x2d40
          nov. 14 14:09:09 cyclope kernel:  ? apparmor_bprm_set_creds+0x1479/0x1f70
          nov. 14 14:09:09 cyclope kernel:  ? security_bprm_set_creds+0x5a/0x80
          nov. 14 14:09:09 cyclope kernel:  ? prepare_binprm+0x366/0x980
          nov. 14 14:09:09 cyclope kernel:  ? do_execveat_common.isra.30+0x12a9/0x2350
          nov. 14 14:09:09 cyclope kernel:  ? SyS_execve+0x2c/0x40
          nov. 14 14:09:09 cyclope kernel:  ? do_syscall_64+0x228/0x650
          nov. 14 14:09:09 cyclope kernel:  ? entry_SYSCALL64_slow_path+0x25/0x25
          nov. 14 14:09:09 cyclope kernel:  ? deactivate_slab.isra.62+0x49d/0x5e0
          nov. 14 14:09:09 cyclope kernel:  ? save_stack_trace+0x16/0x20
          nov. 14 14:09:09 cyclope kernel:  ? init_object+0x88/0x90
          nov. 14 14:09:09 cyclope kernel:  ? ___slab_alloc+0x520/0x590
          nov. 14 14:09:09 cyclope kernel:  ? ___slab_alloc+0x520/0x590
          nov. 14 14:09:09 cyclope kernel:  ? aa_alloc_proxy+0xab/0x200
          nov. 14 14:09:09 cyclope kernel:  ? lock_downgrade+0x7e0/0x7e0
          nov. 14 14:09:09 cyclope kernel:  ? memcg_kmem_get_cache+0x970/0x970
          nov. 14 14:09:09 cyclope kernel:  ? kasan_unpoison_shadow+0x35/0x50
          nov. 14 14:09:09 cyclope kernel:  ? kasan_unpoison_shadow+0x35/0x50
          nov. 14 14:09:09 cyclope kernel:  ? kasan_kmalloc+0xad/0xe0
          nov. 14 14:09:09 cyclope kernel:  ? aa_alloc_proxy+0xab/0x200
          nov. 14 14:09:09 cyclope kernel:  ? kmem_cache_alloc_trace+0x13f/0x290
          nov. 14 14:09:09 cyclope kernel:  ? aa_alloc_proxy+0xab/0x200
          nov. 14 14:09:09 cyclope kernel:  ? aa_alloc_proxy+0xab/0x200
          nov. 14 14:09:09 cyclope kernel:  ? _raw_spin_unlock+0x22/0x30
          nov. 14 14:09:09 cyclope kernel:  ? vec_find+0xa0/0xa0
          nov. 14 14:09:09 cyclope kernel:  ? aa_label_init+0x6f/0x230
          nov. 14 14:09:09 cyclope kernel:  ? __label_insert+0x3e0/0x3e0
          nov. 14 14:09:09 cyclope kernel:  ? kmem_cache_alloc_trace+0x13f/0x290
          nov. 14 14:09:09 cyclope kernel:  ? aa_alloc_profile+0x58/0x200
          nov. 14 14:09:09 cyclope kernel:  mutex_lock_nested+0x16/0x20
          nov. 14 14:09:09 cyclope kernel:  ? mutex_lock_nested+0x16/0x20
          nov. 14 14:09:09 cyclope kernel:  aa_new_null_profile+0x50a/0x960
          nov. 14 14:09:09 cyclope kernel:  ? aa_fqlookupn_profile+0xdc0/0xdc0
          nov. 14 14:09:09 cyclope kernel:  ? aa_compute_fperms+0x4b5/0x640
          nov. 14 14:09:09 cyclope kernel:  ? disconnect.isra.2+0x1b0/0x1b0
          nov. 14 14:09:09 cyclope kernel:  ? aa_str_perms+0x8d/0xe0
          nov. 14 14:09:09 cyclope kernel:  profile_transition+0x932/0x2d40
          nov. 14 14:09:09 cyclope kernel:  ? up_read+0x1a/0x40
          nov. 14 14:09:09 cyclope kernel:  ? ext4_xattr_get+0x15c/0xaf0 [ext4]
          nov. 14 14:09:09 cyclope kernel:  ? x_table_lookup+0x190/0x190
          nov. 14 14:09:09 cyclope kernel:  ? ext4_xattr_ibody_get+0x590/0x590 [ext4]
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? ext4_xattr_security_get+0x1a/0x20 [ext4]
          nov. 14 14:09:09 cyclope kernel:  ? __vfs_getxattr+0x6d/0xa0
          nov. 14 14:09:09 cyclope kernel:  ? get_vfs_caps_from_disk+0x114/0x720
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? tsc_resume+0x10/0x10
          nov. 14 14:09:09 cyclope kernel:  ? get_vfs_caps_from_disk+0x720/0x720
          nov. 14 14:09:09 cyclope kernel:  ? native_sched_clock_from_tsc+0x201/0x2b0
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock_cpu+0x1b/0x170
          nov. 14 14:09:09 cyclope kernel:  ? find_held_lock+0x3c/0x1e0
          nov. 14 14:09:09 cyclope kernel:  ? rb_insert_color_cached+0x1660/0x1660
          nov. 14 14:09:09 cyclope kernel:  apparmor_bprm_set_creds+0x1479/0x1f70
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? handle_onexec+0x31d0/0x31d0
          nov. 14 14:09:09 cyclope kernel:  ? tsc_resume+0x10/0x10
          nov. 14 14:09:09 cyclope kernel:  ? graph_lock+0xd0/0xd0
          nov. 14 14:09:09 cyclope kernel:  ? tsc_resume+0x10/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock_cpu+0x1b/0x170
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock+0x9/0x10
          nov. 14 14:09:09 cyclope kernel:  ? sched_clock_cpu+0x1b/0x170
          nov. 14 14:09:09 cyclope kernel:  ? find_held_lock+0x3c/0x1e0
          nov. 14 14:09:09 cyclope kernel:  security_bprm_set_creds+0x5a/0x80
          nov. 14 14:09:09 cyclope kernel:  prepare_binprm+0x366/0x980
          nov. 14 14:09:09 cyclope kernel:  ? install_exec_creds+0x150/0x150
          nov. 14 14:09:09 cyclope kernel:  ? __might_fault+0x89/0xb0
          nov. 14 14:09:09 cyclope kernel:  ? up_read+0x40/0x40
          nov. 14 14:09:09 cyclope kernel:  ? get_user_arg_ptr.isra.18+0x2c/0x70
          nov. 14 14:09:09 cyclope kernel:  ? count.isra.20.constprop.32+0x7c/0xf0
          nov. 14 14:09:09 cyclope kernel:  do_execveat_common.isra.30+0x12a9/0x2350
          nov. 14 14:09:09 cyclope kernel:  ? prepare_bprm_creds+0x100/0x100
          nov. 14 14:09:09 cyclope kernel:  ? _raw_spin_unlock+0x22/0x30
          nov. 14 14:09:09 cyclope kernel:  ? deactivate_slab.isra.62+0x49d/0x5e0
          nov. 14 14:09:09 cyclope kernel:  ? save_stack_trace+0x16/0x20
          nov. 14 14:09:09 cyclope kernel:  ? init_object+0x88/0x90
          nov. 14 14:09:09 cyclope kernel:  ? ___slab_alloc+0x520/0x590
          nov. 14 14:09:09 cyclope kernel:  ? ___slab_alloc+0x520/0x590
          nov. 14 14:09:09 cyclope kernel:  ? kasan_check_write+0x14/0x20
          nov. 14 14:09:09 cyclope kernel:  ? memcg_kmem_get_cache+0x970/0x970
          nov. 14 14:09:09 cyclope kernel:  ? kasan_unpoison_shadow+0x35/0x50
          nov. 14 14:09:09 cyclope kernel:  ? glob_match+0x730/0x730
          nov. 14 14:09:09 cyclope kernel:  ? kmem_cache_alloc+0x225/0x280
          nov. 14 14:09:09 cyclope kernel:  ? getname_flags+0xb8/0x510
          nov. 14 14:09:09 cyclope kernel:  ? mm_fault_error+0x2e0/0x2e0
          nov. 14 14:09:09 cyclope kernel:  ? getname_flags+0xf6/0x510
          nov. 14 14:09:09 cyclope kernel:  ? ptregs_sys_vfork+0x10/0x10
          nov. 14 14:09:09 cyclope kernel:  SyS_execve+0x2c/0x40
          nov. 14 14:09:09 cyclope kernel:  do_syscall_64+0x228/0x650
          nov. 14 14:09:09 cyclope kernel:  ? syscall_return_slowpath+0x2f0/0x2f0
          nov. 14 14:09:09 cyclope kernel:  ? syscall_return_slowpath+0x167/0x2f0
          nov. 14 14:09:09 cyclope kernel:  ? prepare_exit_to_usermode+0x220/0x220
          nov. 14 14:09:09 cyclope kernel:  ? prepare_exit_to_usermode+0xda/0x220
          nov. 14 14:09:09 cyclope kernel:  ? perf_trace_sys_enter+0x1060/0x1060
          nov. 14 14:09:09 cyclope kernel:  ? __put_user_4+0x1c/0x30
          nov. 14 14:09:09 cyclope kernel:  entry_SYSCALL64_slow_path+0x25/0x25
          nov. 14 14:09:09 cyclope kernel: RIP: 0033:0x7f9320f23637
          nov. 14 14:09:09 cyclope kernel: RSP: 002b:00007fff783be338 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
          nov. 14 14:09:09 cyclope kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9320f23637
          nov. 14 14:09:09 cyclope kernel: RDX: 0000558c35002a70 RSI: 0000558c3505bd10 RDI: 0000558c35018b90
          nov. 14 14:09:09 cyclope kernel: RBP: 0000558c34b63ae8 R08: 0000558c3505bd10 R09: 0000000000000080
          nov. 14 14:09:09 cyclope kernel: R10: 0000000000000095 R11: 0000000000000202 R12: 0000000000000001
          nov. 14 14:09:09 cyclope kernel: R13: 0000558c35018b90 R14: 0000558c3505bd18 R15: 0000558c3505bd10
      
      Fixes: 4227c333 ("apparmor: Move path lookup to using preallocated buffers")
      BugLink: http://bugs.launchpad.net/bugs/173228Reported-by: default avatarAlban Browaeys <prahal@yahoo.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      5d7c44ef
    • John Johansen's avatar
      apparmor: fix profile attachment for special unconfined profiles · 06d426d1
      John Johansen authored
      It used to be that unconfined would never attach. However that is not
      the case anymore as some special profiles can be marked as unconfined,
      that are not the namespaces unconfined profile, and may have an
      attachment.
      
      Fixes: f1bd9041 ("apparmor: add the base fns() for domain labels")
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      06d426d1
    • John Johansen's avatar
      apparmor: ensure that undecidable profile attachments fail · 844b8292
      John Johansen authored
      Profiles that have an undecidable overlap in their attachments are
      being incorrectly handled. Instead of failing to attach the first one
      encountered is being used.
      
      eg.
        profile A /** { .. }
        profile B /*foo { .. }
      
      have an unresolvable longest left attachment, they both have an exact
      match on / and then have an overlapping expression that has no clear
      winner.
      
      Currently the winner will be the profile that is loaded first which
      can result in non-deterministic behavior. Instead in this situation
      the exec should fail.
      
      Fixes: 898127c3 ("AppArmor: functions for domain transitions")
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      844b8292
    • John Johansen's avatar
      apparmor: fix leak of null profile name if profile allocation fails · 4633307e
      John Johansen authored
      Fixes: d07881d2 ("apparmor: move new_null_profile to after profile lookup fns()")
      Reported-by: default avatarSeth Arnold <seth.arnold@canonical.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      4633307e
    • Colin Ian King's avatar
      apparmor: remove unused redundant variable stop · e3bcfc14
      Colin Ian King authored
      The boolean variable 'stop' is being set but never read. This
      is a redundant variable and can be removed.
      
      Cleans up clang warning: Value stored to 'stop' is never read
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      e3bcfc14
    • Thomas Meyer's avatar
      apparmor: Fix bool initialization/comparison · 954317fe
      Thomas Meyer authored
      Bool initializations should use true and false. Bool tests don't need
      comparisons.
      Signed-off-by: default avatarThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      954317fe
    • Arnd Bergmann's avatar
      apparmor: initialized returned struct aa_perms · 7bba39ae
      Arnd Bergmann authored
      gcc-4.4 points out suspicious code in compute_mnt_perms, where
      the aa_perms structure is only partially initialized before getting
      returned:
      
      security/apparmor/mount.c: In function 'compute_mnt_perms':
      security/apparmor/mount.c:227: error: 'perms.prompt' is used uninitialized in this function
      security/apparmor/mount.c:227: error: 'perms.hide' is used uninitialized in this function
      security/apparmor/mount.c:227: error: 'perms.cond' is used uninitialized in this function
      security/apparmor/mount.c:227: error: 'perms.complain' is used uninitialized in this function
      security/apparmor/mount.c:227: error: 'perms.stop' is used uninitialized in this function
      security/apparmor/mount.c:227: error: 'perms.deny' is used uninitialized in this function
      
      Returning or assigning partially initialized structures is a bit tricky,
      in particular it is explicitly allowed in c99 to assign a partially
      initialized structure to another, as long as only members are read that
      have been initialized earlier. Looking at what various compilers do here,
      the version that produced the warning copied uninitialized stack data,
      while newer versions (and also clang) either set the other members to
      zero or don't update the parts of the return buffer that are not modified
      in the temporary structure, but they never warn about this.
      
      In case of apparmor, it seems better to be a little safer and always
      initialize the aa_perms structure. Most users already do that, this
      changes the remaining ones, including the one instance that I got the
      warning for.
      
      Fixes: fa488437d0f9 ("apparmor: add mount mediation")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarSeth Arnold <seth.arnold@canonical.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      7bba39ae
    • Colin Ian King's avatar
      apparmor: fix spelling mistake: "resoure" -> "resource" · 5933a627
      Colin Ian King authored
      Trivial fix to spelling mistake in comment and also with text in
      audit_resource call.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      5933a627
  3. 19 Nov, 2017 1 commit
    • Roberto Sassu's avatar
      ima: do not update security.ima if appraisal status is not INTEGRITY_PASS · 020aae3e
      Roberto Sassu authored
      Commit b65a9cfc ("Untangling ima mess, part 2: deal with counters")
      moved the call of ima_file_check() from may_open() to do_filp_open() at a
      point where the file descriptor is already opened.
      
      This breaks the assumption made by IMA that file descriptors being closed
      belong to files whose access was granted by ima_file_check(). The
      consequence is that security.ima and security.evm are updated with good
      values, regardless of the current appraisal status.
      
      For example, if a file does not have security.ima, IMA will create it after
      opening the file for writing, even if access is denied. Access to the file
      will be allowed afterwards.
      
      Avoid this issue by checking the appraisal status before updating
      security.ima.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@huawei.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      020aae3e
  4. 15 Nov, 2017 2 commits
  5. 08 Nov, 2017 11 commits
  6. 05 Nov, 2017 2 commits
  7. 03 Nov, 2017 1 commit
  8. 02 Nov, 2017 4 commits
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
    • Eric Biggers's avatar
      KEYS: trusted: fix writing past end of buffer in trusted_read() · a3c812f7
      Eric Biggers authored
      When calling keyctl_read() on a key of type "trusted", if the
      user-supplied buffer was too small, the kernel ignored the buffer length
      and just wrote past the end of the buffer, potentially corrupting
      userspace memory.  Fix it by instead returning the size required, as per
      the documentation for keyctl_read().
      
      We also don't even fill the buffer at all in this case, as this is
      slightly easier to implement than doing a short read, and either
      behavior appears to be permitted.  It also makes it match the behavior
      of the "encrypted" key type.
      
      Fixes: d00a1c72 ("keys: add new trusted key-type")
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: <stable@vger.kernel.org> # v2.6.38+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      a3c812f7
    • Eric Biggers's avatar
      KEYS: return full count in keyring_read() if buffer is too small · 3239b6f2
      Eric Biggers authored
      Commit e645016a ("KEYS: fix writing past end of user-supplied buffer
      in keyring_read()") made keyring_read() stop corrupting userspace memory
      when the user-supplied buffer is too small.  However it also made the
      return value in that case be the short buffer size rather than the size
      required, yet keyctl_read() is actually documented to return the size
      required.  Therefore, switch it over to the documented behavior.
      
      Note that for now we continue to have it fill the short buffer, since it
      did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably
      relies on it.
      
      Fixes: e645016a ("KEYS: fix writing past end of user-supplied buffer in keyring_read()")
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: <stable@vger.kernel.org> # v3.13+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      3239b6f2
    • Casey Schaufler's avatar
      Smack: Base support for overlayfs · d6d80cb5
      Casey Schaufler authored
      Supply the Smack module hooks in support of overlayfs.
      Ensure that the Smack label of new files gets the correct
      value when a directory is transmuting. Original implementation
      by Romanini Daniele, with a few tweaks added.
      Signed-off-by: default avatarRomanini Daniele <daniele.romanini@aalto.fi>
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      d6d80cb5
  9. 31 Oct, 2017 1 commit
    • Kees Cook's avatar
      treewide: Fix function prototypes for module_param_call() · e4dca7b7
      Kees Cook authored
      Several function prototypes for the set/get functions defined by
      module_param_call() have a slightly wrong argument types. This fixes
      those in an effort to clean up the calls when running under type-enforced
      compiler instrumentation for CFI. This is the result of running the
      following semantic patch:
      
      @match_module_param_call_function@
      declarer name module_param_call;
      identifier _name, _set_func, _get_func;
      expression _arg, _mode;
      @@
      
       module_param_call(_name, _set_func, _get_func, _arg, _mode);
      
      @fix_set_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._set_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _set_func(
      -_val_type _val
      +const char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      @fix_get_prototype
       depends on match_module_param_call_function@
      identifier match_module_param_call_function._get_func;
      identifier _val, _param;
      type _val_type, _param_type;
      @@
      
       int _get_func(
      -_val_type _val
      +char * _val
       ,
      -_param_type _param
      +const struct kernel_param * _param
       ) { ... }
      
      Two additional by-hand changes are included for places where the above
      Coccinelle script didn't notice them:
      
      	drivers/platform/x86/thinkpad_acpi.c
      	fs/lockd/svc.c
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJessica Yu <jeyu@kernel.org>
      e4dca7b7
  10. 26 Oct, 2017 1 commit
  11. 21 Oct, 2017 1 commit
  12. 20 Oct, 2017 4 commits