| Message ID | 20200124002306.3552-1-casey@schaufler-ca.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | LSM: Module stacking for AppArmor | expand |
On 1/23/20 7:22 PM, Casey Schaufler wrote: > This patchset provides the changes required for > the AppArmor security module to stack safely with any other. > > v14: Rebase to 5.5-rc5 > Incorporate feedback from v13 > - Use an array of audit rules (patch 0002) > - Significant change, removed Acks (patch 0002) > - Remove unneeded include (patch 0013) > - Use context.len correctly (patch 0015) > - Reorder code to be more sensible (patch 0016) > - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) Looks like you also dropped "LSM: Use lsmcontext in security_dentry_init_security" entirely (was patch 16 in v13).
On 1/23/20 7:22 PM, Casey Schaufler wrote: > This patchset provides the changes required for > the AppArmor security module to stack safely with any other. > > v14: Rebase to 5.5-rc5 > Incorporate feedback from v13 > - Use an array of audit rules (patch 0002) > - Significant change, removed Acks (patch 0002) > - Remove unneeded include (patch 0013) > - Use context.len correctly (patch 0015) > - Reorder code to be more sensible (patch 0016) > - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) I don't know for sure if this is your bug, but it happens every time I boot with your patches applied and not at all on stock v5.5-rc5 so here it is. Will try to bisect as time permits but not until next week. Trigger seems to be loading the tun driver. [ 67.726834] tun: Universal TUN/TAP device driver, 1.6 [ 67.736657] ================================================================== [ 67.741335] BUG: KASAN: slab-out-of-bounds in sock_init_data+0x14a/0x5a0 [ 67.745037] Read of size 4 at addr ffff88870afe8928 by task libvirtd/1238 [ 67.751861] CPU: 4 PID: 1238 Comm: libvirtd Tainted: G T 5.5.0-rc5+ #54 [ 67.756250] Call Trace: [ 67.759510] dump_stack+0xb8/0x110 [ 67.761604] print_address_description.constprop.0+0x1f/0x280 [ 67.763768] __kasan_report.cold+0x75/0x8f [ 67.765895] ? sock_init_data+0x14a/0x5a0 [ 67.768282] kasan_report+0xe/0x20 [ 67.770397] sock_init_data+0x14a/0x5a0 [ 67.772511] tun_chr_open+0x1de/0x280 [tun] [ 67.774644] misc_open+0x1cb/0x210 [ 67.776820] chrdev_open+0x15b/0x350 [ 67.778917] ? cdev_put.part.0+0x30/0x30 [ 67.781030] do_dentry_open+0x2cb/0x800 [ 67.783135] ? cdev_put.part.0+0x30/0x30 [ 67.785225] ? devcgroup_check_permission+0x11a/0x260 [ 67.787321] ? __x64_sys_fchdir+0xf0/0xf0 [ 67.789418] ? security_inode_permission+0x5b/0x70 [ 67.791513] path_openat+0x858/0x14a0 [ 67.793589] ? path_mountpoint+0x5e0/0x5e0 [ 67.795719] ? mark_lock+0xb8/0xb00 [ 67.797786] do_filp_open+0x11e/0x1b0 [ 67.799840] ? may_open_dev+0x60/0x60 [ 67.801871] ? match_held_lock+0x1b/0x240 [ 67.803968] ? lock_downgrade+0x360/0x360 [ 67.805997] ? do_raw_spin_lock+0x119/0x1d0 [ 67.808041] ? rwlock_bug.part.0+0x60/0x60 [ 67.810099] ? do_raw_spin_unlock+0xa3/0x130 [ 67.812244] ? _raw_spin_unlock+0x1f/0x30 [ 67.814287] ? __alloc_fd+0x143/0x2f0 [ 67.816324] do_sys_open+0x1f0/0x2d0 [ 67.818358] ? filp_open+0x50/0x50 [ 67.820404] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 67.822447] ? lockdep_hardirqs_off+0xbe/0x100 [ 67.824473] ? mark_held_locks+0x24/0x90 [ 67.826484] do_syscall_64+0x74/0xd0 [ 67.828480] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 67.830478] RIP: 0033:0x7f1a2cce6074 [ 67.832495] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 86 f4 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 b8 f4 ff ff 8b 44 [ 67.834760] RSP: 002b:00007f19e4af46d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [ 67.837032] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1a2cce6074 [ 67.839318] RDX: 0000000000000002 RSI: 00007f1a2d0bfb67 RDI: 00000000ffffff9c [ 67.841598] RBP: 00007f1a2d0bfb67 R08: 0000000000000000 R09: 00007f19e4af4914 [ 67.843941] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002 [ 67.846283] R13: 000000000000000d R14: 00007f19e4af4920 R15: 00007f1a2d0bfb67 [ 67.850936] Allocated by task 1238: [ 67.853241] save_stack+0x1b/0x80 [ 67.855533] __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 67.857935] sk_prot_alloc+0x115/0x170 [ 67.860235] sk_alloc+0x2f/0xa10 [ 67.862541] tun_chr_open+0x4d/0x280 [tun] [ 67.864894] misc_open+0x1cb/0x210 [ 67.867164] chrdev_open+0x15b/0x350 [ 67.869448] do_dentry_open+0x2cb/0x800 [ 67.871768] path_openat+0x858/0x14a0 [ 67.874041] do_filp_open+0x11e/0x1b0 [ 67.876328] do_sys_open+0x1f0/0x2d0 [ 67.878592] do_syscall_64+0x74/0xd0 [ 67.880899] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 67.885431] Freed by task 726: [ 67.887689] save_stack+0x1b/0x80 [ 67.889967] __kasan_slab_free+0x12c/0x170 [ 67.892197] kfree+0xff/0x430 [ 67.894444] uevent_show+0x176/0x1b0 [ 67.896709] dev_attr_show+0x37/0x70 [ 67.898940] sysfs_kf_seq_show+0x119/0x210 [ 67.901159] seq_read+0x29d/0x720 [ 67.903367] vfs_read+0xf9/0x1f0 [ 67.905538] ksys_read+0xc9/0x160 [ 67.907736] do_syscall_64+0x74/0xd0 [ 67.909889] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 67.914100] The buggy address belongs to the object at ffff88870afe8000 which belongs to the cache kmalloc-4k of size 4096 [ 67.918357] The buggy address is located 2344 bytes inside of 4096-byte region [ffff88870afe8000, ffff88870afe9000) [ 67.922562] The buggy address belongs to the page: [ 67.924725] page:ffffea001c2bfa00 refcount:1 mapcount:0 mapping:ffff88881f00de00 index:0x0 compound_mapcount: 0 [ 67.926926] raw: 0017ffe000010200 ffffea001c167a00 0000000200000002 ffff88881f00de00 [ 67.929144] raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000 [ 67.931362] page dumped because: kasan: bad access detected [ 67.936192] Memory state around the buggy address: [ 67.938438] ffff88870afe8800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.941078] ffff88870afe8880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.943393] >ffff88870afe8900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.945709] ^ [ 67.948000] ffff88870afe8980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.950311] ffff88870afe8a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.952629] ==================================================================
On 1/24/2020 1:04 PM, Stephen Smalley wrote: > On 1/23/20 7:22 PM, Casey Schaufler wrote: >> This patchset provides the changes required for >> the AppArmor security module to stack safely with any other. >> >> v14: Rebase to 5.5-rc5 >> Incorporate feedback from v13 >> - Use an array of audit rules (patch 0002) >> - Significant change, removed Acks (patch 0002) >> - Remove unneeded include (patch 0013) >> - Use context.len correctly (patch 0015) >> - Reorder code to be more sensible (patch 0016) >> - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) > > I don't know for sure if this is your bug, but it happens every time I boot with your patches applied and not at all on stock v5.5-rc5 so here it is. Will try to bisect as time permits but not until next week. Trigger seems to be loading the tun driver. Thanks. I will have a look as well. > > [ 67.726834] tun: Universal TUN/TAP device driver, 1.6 > [ 67.736657] ================================================================== > [ 67.741335] BUG: KASAN: slab-out-of-bounds in sock_init_data+0x14a/0x5a0 > [ 67.745037] Read of size 4 at addr ffff88870afe8928 by task libvirtd/1238 > > [ 67.751861] CPU: 4 PID: 1238 Comm: libvirtd Tainted: G T 5.5.0-rc5+ #54 > [ 67.756250] Call Trace: > [ 67.759510] dump_stack+0xb8/0x110 > [ 67.761604] print_address_description.constprop.0+0x1f/0x280 > [ 67.763768] __kasan_report.cold+0x75/0x8f > [ 67.765895] ? sock_init_data+0x14a/0x5a0 > [ 67.768282] kasan_report+0xe/0x20 > [ 67.770397] sock_init_data+0x14a/0x5a0 > [ 67.772511] tun_chr_open+0x1de/0x280 [tun] > [ 67.774644] misc_open+0x1cb/0x210 > [ 67.776820] chrdev_open+0x15b/0x350 > [ 67.778917] ? cdev_put.part.0+0x30/0x30 > [ 67.781030] do_dentry_open+0x2cb/0x800 > [ 67.783135] ? cdev_put.part.0+0x30/0x30 > [ 67.785225] ? devcgroup_check_permission+0x11a/0x260 > [ 67.787321] ? __x64_sys_fchdir+0xf0/0xf0 > [ 67.789418] ? security_inode_permission+0x5b/0x70 > [ 67.791513] path_openat+0x858/0x14a0 > [ 67.793589] ? path_mountpoint+0x5e0/0x5e0 > [ 67.795719] ? mark_lock+0xb8/0xb00 > [ 67.797786] do_filp_open+0x11e/0x1b0 > [ 67.799840] ? may_open_dev+0x60/0x60 > [ 67.801871] ? match_held_lock+0x1b/0x240 > [ 67.803968] ? lock_downgrade+0x360/0x360 > [ 67.805997] ? do_raw_spin_lock+0x119/0x1d0 > [ 67.808041] ? rwlock_bug.part.0+0x60/0x60 > [ 67.810099] ? do_raw_spin_unlock+0xa3/0x130 > [ 67.812244] ? _raw_spin_unlock+0x1f/0x30 > [ 67.814287] ? __alloc_fd+0x143/0x2f0 > [ 67.816324] do_sys_open+0x1f0/0x2d0 > [ 67.818358] ? filp_open+0x50/0x50 > [ 67.820404] ? trace_hardirqs_on_thunk+0x1a/0x1c > [ 67.822447] ? lockdep_hardirqs_off+0xbe/0x100 > [ 67.824473] ? mark_held_locks+0x24/0x90 > [ 67.826484] do_syscall_64+0x74/0xd0 > [ 67.828480] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 67.830478] RIP: 0033:0x7f1a2cce6074 > [ 67.832495] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 86 f4 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 b8 f4 ff ff 8b 44 > [ 67.834760] RSP: 002b:00007f19e4af46d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 > [ 67.837032] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1a2cce6074 > [ 67.839318] RDX: 0000000000000002 RSI: 00007f1a2d0bfb67 RDI: 00000000ffffff9c > [ 67.841598] RBP: 00007f1a2d0bfb67 R08: 0000000000000000 R09: 00007f19e4af4914 > [ 67.843941] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002 > [ 67.846283] R13: 000000000000000d R14: 00007f19e4af4920 R15: 00007f1a2d0bfb67 > > [ 67.850936] Allocated by task 1238: > [ 67.853241] save_stack+0x1b/0x80 > [ 67.855533] __kasan_kmalloc.constprop.0+0xc2/0xd0 > [ 67.857935] sk_prot_alloc+0x115/0x170 > [ 67.860235] sk_alloc+0x2f/0xa10 > [ 67.862541] tun_chr_open+0x4d/0x280 [tun] > [ 67.864894] misc_open+0x1cb/0x210 > [ 67.867164] chrdev_open+0x15b/0x350 > [ 67.869448] do_dentry_open+0x2cb/0x800 > [ 67.871768] path_openat+0x858/0x14a0 > [ 67.874041] do_filp_open+0x11e/0x1b0 > [ 67.876328] do_sys_open+0x1f0/0x2d0 > [ 67.878592] do_syscall_64+0x74/0xd0 > [ 67.880899] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 67.885431] Freed by task 726: > [ 67.887689] save_stack+0x1b/0x80 > [ 67.889967] __kasan_slab_free+0x12c/0x170 > [ 67.892197] kfree+0xff/0x430 > [ 67.894444] uevent_show+0x176/0x1b0 > [ 67.896709] dev_attr_show+0x37/0x70 > [ 67.898940] sysfs_kf_seq_show+0x119/0x210 > [ 67.901159] seq_read+0x29d/0x720 > [ 67.903367] vfs_read+0xf9/0x1f0 > [ 67.905538] ksys_read+0xc9/0x160 > [ 67.907736] do_syscall_64+0x74/0xd0 > [ 67.909889] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 67.914100] The buggy address belongs to the object at ffff88870afe8000 > which belongs to the cache kmalloc-4k of size 4096 > [ 67.918357] The buggy address is located 2344 bytes inside of > 4096-byte region [ffff88870afe8000, ffff88870afe9000) > [ 67.922562] The buggy address belongs to the page: > [ 67.924725] page:ffffea001c2bfa00 refcount:1 mapcount:0 mapping:ffff88881f00de00 index:0x0 compound_mapcount: 0 > [ 67.926926] raw: 0017ffe000010200 ffffea001c167a00 0000000200000002 ffff88881f00de00 > [ 67.929144] raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000 > [ 67.931362] page dumped because: kasan: bad access detected > > [ 67.936192] Memory state around the buggy address: > [ 67.938438] ffff88870afe8800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > [ 67.941078] ffff88870afe8880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > [ 67.943393] >ffff88870afe8900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > [ 67.945709] ^ > [ 67.948000] ffff88870afe8980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > [ 67.950311] ffff88870afe8a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > [ 67.952629] ==================================================================
On 1/24/20 4:49 PM, Casey Schaufler wrote: > On 1/24/2020 1:04 PM, Stephen Smalley wrote: >> On 1/23/20 7:22 PM, Casey Schaufler wrote: >>> This patchset provides the changes required for >>> the AppArmor security module to stack safely with any other. >>> >>> v14: Rebase to 5.5-rc5 >>> Incorporate feedback from v13 >>> - Use an array of audit rules (patch 0002) >>> - Significant change, removed Acks (patch 0002) >>> - Remove unneeded include (patch 0013) >>> - Use context.len correctly (patch 0015) >>> - Reorder code to be more sensible (patch 0016) >>> - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) >> >> I don't know for sure if this is your bug, but it happens every time I boot with your patches applied and not at all on stock v5.5-rc5 so here it is. Will try to bisect as time permits but not until next week. Trigger seems to be loading the tun driver. > > Thanks. I will have a look as well. Bisection led to the first patch in the series, "LSM: Infrastructure management of the sock security". Still not sure if the bug is in the patch itself or just being surfaced by it. >> >> [ 67.726834] tun: Universal TUN/TAP device driver, 1.6 >> [ 67.736657] ================================================================== >> [ 67.741335] BUG: KASAN: slab-out-of-bounds in sock_init_data+0x14a/0x5a0 >> [ 67.745037] Read of size 4 at addr ffff88870afe8928 by task libvirtd/1238 >> >> [ 67.751861] CPU: 4 PID: 1238 Comm: libvirtd Tainted: G T 5.5.0-rc5+ #54 >> [ 67.756250] Call Trace: >> [ 67.759510] dump_stack+0xb8/0x110 >> [ 67.761604] print_address_description.constprop.0+0x1f/0x280 >> [ 67.763768] __kasan_report.cold+0x75/0x8f >> [ 67.765895] ? sock_init_data+0x14a/0x5a0 >> [ 67.768282] kasan_report+0xe/0x20 >> [ 67.770397] sock_init_data+0x14a/0x5a0 >> [ 67.772511] tun_chr_open+0x1de/0x280 [tun] >> [ 67.774644] misc_open+0x1cb/0x210 >> [ 67.776820] chrdev_open+0x15b/0x350 >> [ 67.778917] ? cdev_put.part.0+0x30/0x30 >> [ 67.781030] do_dentry_open+0x2cb/0x800 >> [ 67.783135] ? cdev_put.part.0+0x30/0x30 >> [ 67.785225] ? devcgroup_check_permission+0x11a/0x260 >> [ 67.787321] ? __x64_sys_fchdir+0xf0/0xf0 >> [ 67.789418] ? security_inode_permission+0x5b/0x70 >> [ 67.791513] path_openat+0x858/0x14a0 >> [ 67.793589] ? path_mountpoint+0x5e0/0x5e0 >> [ 67.795719] ? mark_lock+0xb8/0xb00 >> [ 67.797786] do_filp_open+0x11e/0x1b0 >> [ 67.799840] ? may_open_dev+0x60/0x60 >> [ 67.801871] ? match_held_lock+0x1b/0x240 >> [ 67.803968] ? lock_downgrade+0x360/0x360 >> [ 67.805997] ? do_raw_spin_lock+0x119/0x1d0 >> [ 67.808041] ? rwlock_bug.part.0+0x60/0x60 >> [ 67.810099] ? do_raw_spin_unlock+0xa3/0x130 >> [ 67.812244] ? _raw_spin_unlock+0x1f/0x30 >> [ 67.814287] ? __alloc_fd+0x143/0x2f0 >> [ 67.816324] do_sys_open+0x1f0/0x2d0 >> [ 67.818358] ? filp_open+0x50/0x50 >> [ 67.820404] ? trace_hardirqs_on_thunk+0x1a/0x1c >> [ 67.822447] ? lockdep_hardirqs_off+0xbe/0x100 >> [ 67.824473] ? mark_held_locks+0x24/0x90 >> [ 67.826484] do_syscall_64+0x74/0xd0 >> [ 67.828480] entry_SYSCALL_64_after_hwframe+0x49/0xbe >> [ 67.830478] RIP: 0033:0x7f1a2cce6074 >> [ 67.832495] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 86 f4 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 b8 f4 ff ff 8b 44 >> [ 67.834760] RSP: 002b:00007f19e4af46d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 >> [ 67.837032] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1a2cce6074 >> [ 67.839318] RDX: 0000000000000002 RSI: 00007f1a2d0bfb67 RDI: 00000000ffffff9c >> [ 67.841598] RBP: 00007f1a2d0bfb67 R08: 0000000000000000 R09: 00007f19e4af4914 >> [ 67.843941] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002 >> [ 67.846283] R13: 000000000000000d R14: 00007f19e4af4920 R15: 00007f1a2d0bfb67 >> >> [ 67.850936] Allocated by task 1238: >> [ 67.853241] save_stack+0x1b/0x80 >> [ 67.855533] __kasan_kmalloc.constprop.0+0xc2/0xd0 >> [ 67.857935] sk_prot_alloc+0x115/0x170 >> [ 67.860235] sk_alloc+0x2f/0xa10 >> [ 67.862541] tun_chr_open+0x4d/0x280 [tun] >> [ 67.864894] misc_open+0x1cb/0x210 >> [ 67.867164] chrdev_open+0x15b/0x350 >> [ 67.869448] do_dentry_open+0x2cb/0x800 >> [ 67.871768] path_openat+0x858/0x14a0 >> [ 67.874041] do_filp_open+0x11e/0x1b0 >> [ 67.876328] do_sys_open+0x1f0/0x2d0 >> [ 67.878592] do_syscall_64+0x74/0xd0 >> [ 67.880899] entry_SYSCALL_64_after_hwframe+0x49/0xbe >> >> [ 67.885431] Freed by task 726: >> [ 67.887689] save_stack+0x1b/0x80 >> [ 67.889967] __kasan_slab_free+0x12c/0x170 >> [ 67.892197] kfree+0xff/0x430 >> [ 67.894444] uevent_show+0x176/0x1b0 >> [ 67.896709] dev_attr_show+0x37/0x70 >> [ 67.898940] sysfs_kf_seq_show+0x119/0x210 >> [ 67.901159] seq_read+0x29d/0x720 >> [ 67.903367] vfs_read+0xf9/0x1f0 >> [ 67.905538] ksys_read+0xc9/0x160 >> [ 67.907736] do_syscall_64+0x74/0xd0 >> [ 67.909889] entry_SYSCALL_64_after_hwframe+0x49/0xbe >> >> [ 67.914100] The buggy address belongs to the object at ffff88870afe8000 >> which belongs to the cache kmalloc-4k of size 4096 >> [ 67.918357] The buggy address is located 2344 bytes inside of >> 4096-byte region [ffff88870afe8000, ffff88870afe9000) >> [ 67.922562] The buggy address belongs to the page: >> [ 67.924725] page:ffffea001c2bfa00 refcount:1 mapcount:0 mapping:ffff88881f00de00 index:0x0 compound_mapcount: 0 >> [ 67.926926] raw: 0017ffe000010200 ffffea001c167a00 0000000200000002 ffff88881f00de00 >> [ 67.929144] raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000 >> [ 67.931362] page dumped because: kasan: bad access detected >> >> [ 67.936192] Memory state around the buggy address: >> [ 67.938438] ffff88870afe8800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> [ 67.941078] ffff88870afe8880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> [ 67.943393] >ffff88870afe8900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> [ 67.945709] ^ >> [ 67.948000] ffff88870afe8980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> [ 67.950311] ffff88870afe8a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> [ 67.952629] ==================================================================
On 1/27/20 11:14 AM, Stephen Smalley wrote: > On 1/24/20 4:49 PM, Casey Schaufler wrote: >> On 1/24/2020 1:04 PM, Stephen Smalley wrote: >>> On 1/23/20 7:22 PM, Casey Schaufler wrote: >>>> This patchset provides the changes required for >>>> the AppArmor security module to stack safely with any other. >>>> >>>> v14: Rebase to 5.5-rc5 >>>> Incorporate feedback from v13 >>>> - Use an array of audit rules (patch 0002) >>>> - Significant change, removed Acks (patch 0002) >>>> - Remove unneeded include (patch 0013) >>>> - Use context.len correctly (patch 0015) >>>> - Reorder code to be more sensible (patch 0016) >>>> - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) >>> >>> I don't know for sure if this is your bug, but it happens every time >>> I boot with your patches applied and not at all on stock v5.5-rc5 so >>> here it is. Will try to bisect as time permits but not until next >>> week. Trigger seems to be loading the tun driver. >> >> Thanks. I will have a look as well. > > Bisection led to the first patch in the series, "LSM: Infrastructure > management of the sock security". Still not sure if the bug is in the > patch itself or just being surfaced by it. Looks like the bug is pre-existing to me and just exposed by your patch. tun_chr_open() is creating a struct tun_file via sk_alloc() with its own tun_proto with a custom .obj_size. It then passes the tun_file->socket and ->sk fields to sock_init_data(). sock_init_data() assumes it can safely use SOCK_INODE(sock) if sock is non-NULL, which means that it presumes all such sockets were wrapped in a struct socket_alloc. But this one wasn't. I don't know if that's a bug in the tun driver for not wrapping its socket in a socket_alloc or in sock_init_data() for assuming that all sockets it is passed have been so wrapped. KASAN is tripping on this assignment in sock_init_data(): net/core/sock.c: 2871 sk->sk_uid = SOCK_INODE(sock)->i_uid; This appears to have been broken since commit 86741ec25462e4c8cdce6df2f41ead05568c7d5e ("net: core: Add a UID field to struct sock."). Previously reported here by someone else with RFC patches: https://lore.kernel.org/netdev/20190929110502.2284-1-amade@asmblr.net/ > >>> >>> [ 67.726834] tun: Universal TUN/TAP device driver, 1.6 >>> [ 67.736657] >>> ================================================================== >>> [ 67.741335] BUG: KASAN: slab-out-of-bounds in >>> sock_init_data+0x14a/0x5a0 >>> [ 67.745037] Read of size 4 at addr ffff88870afe8928 by task >>> libvirtd/1238 >>> >>> [ 67.751861] CPU: 4 PID: 1238 Comm: libvirtd Tainted: G T >>> 5.5.0-rc5+ #54 >>> [ 67.756250] Call Trace: >>> [ 67.759510] dump_stack+0xb8/0x110 >>> [ 67.761604] print_address_description.constprop.0+0x1f/0x280 >>> [ 67.763768] __kasan_report.cold+0x75/0x8f >>> [ 67.765895] ? sock_init_data+0x14a/0x5a0 >>> [ 67.768282] kasan_report+0xe/0x20 >>> [ 67.770397] sock_init_data+0x14a/0x5a0 >>> [ 67.772511] tun_chr_open+0x1de/0x280 [tun] >>> [ 67.774644] misc_open+0x1cb/0x210 >>> [ 67.776820] chrdev_open+0x15b/0x350 >>> [ 67.778917] ? cdev_put.part.0+0x30/0x30 >>> [ 67.781030] do_dentry_open+0x2cb/0x800 >>> [ 67.783135] ? cdev_put.part.0+0x30/0x30 >>> [ 67.785225] ? devcgroup_check_permission+0x11a/0x260 >>> [ 67.787321] ? __x64_sys_fchdir+0xf0/0xf0 >>> [ 67.789418] ? security_inode_permission+0x5b/0x70 >>> [ 67.791513] path_openat+0x858/0x14a0 >>> [ 67.793589] ? path_mountpoint+0x5e0/0x5e0 >>> [ 67.795719] ? mark_lock+0xb8/0xb00 >>> [ 67.797786] do_filp_open+0x11e/0x1b0 >>> [ 67.799840] ? may_open_dev+0x60/0x60 >>> [ 67.801871] ? match_held_lock+0x1b/0x240 >>> [ 67.803968] ? lock_downgrade+0x360/0x360 >>> [ 67.805997] ? do_raw_spin_lock+0x119/0x1d0 >>> [ 67.808041] ? rwlock_bug.part.0+0x60/0x60 >>> [ 67.810099] ? do_raw_spin_unlock+0xa3/0x130 >>> [ 67.812244] ? _raw_spin_unlock+0x1f/0x30 >>> [ 67.814287] ? __alloc_fd+0x143/0x2f0 >>> [ 67.816324] do_sys_open+0x1f0/0x2d0 >>> [ 67.818358] ? filp_open+0x50/0x50 >>> [ 67.820404] ? trace_hardirqs_on_thunk+0x1a/0x1c >>> [ 67.822447] ? lockdep_hardirqs_off+0xbe/0x100 >>> [ 67.824473] ? mark_held_locks+0x24/0x90 >>> [ 67.826484] do_syscall_64+0x74/0xd0 >>> [ 67.828480] entry_SYSCALL_64_after_hwframe+0x49/0xbe >>> [ 67.830478] RIP: 0033:0x7f1a2cce6074 >>> [ 67.832495] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 86 f4 ff ff >>> 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 >>> 00 0f 05 <48> 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 b8 f4 ff >>> ff 8b 44 >>> [ 67.834760] RSP: 002b:00007f19e4af46d0 EFLAGS: 00000293 ORIG_RAX: >>> 0000000000000101 >>> [ 67.837032] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: >>> 00007f1a2cce6074 >>> [ 67.839318] RDX: 0000000000000002 RSI: 00007f1a2d0bfb67 RDI: >>> 00000000ffffff9c >>> [ 67.841598] RBP: 00007f1a2d0bfb67 R08: 0000000000000000 R09: >>> 00007f19e4af4914 >>> [ 67.843941] R10: 0000000000000000 R11: 0000000000000293 R12: >>> 0000000000000002 >>> [ 67.846283] R13: 000000000000000d R14: 00007f19e4af4920 R15: >>> 00007f1a2d0bfb67 >>> >>> [ 67.850936] Allocated by task 1238: >>> [ 67.853241] save_stack+0x1b/0x80 >>> [ 67.855533] __kasan_kmalloc.constprop.0+0xc2/0xd0 >>> [ 67.857935] sk_prot_alloc+0x115/0x170 >>> [ 67.860235] sk_alloc+0x2f/0xa10 >>> [ 67.862541] tun_chr_open+0x4d/0x280 [tun] >>> [ 67.864894] misc_open+0x1cb/0x210 >>> [ 67.867164] chrdev_open+0x15b/0x350 >>> [ 67.869448] do_dentry_open+0x2cb/0x800 >>> [ 67.871768] path_openat+0x858/0x14a0 >>> [ 67.874041] do_filp_open+0x11e/0x1b0 >>> [ 67.876328] do_sys_open+0x1f0/0x2d0 >>> [ 67.878592] do_syscall_64+0x74/0xd0 >>> [ 67.880899] entry_SYSCALL_64_after_hwframe+0x49/0xbe >>> >>> [ 67.885431] Freed by task 726: >>> [ 67.887689] save_stack+0x1b/0x80 >>> [ 67.889967] __kasan_slab_free+0x12c/0x170 >>> [ 67.892197] kfree+0xff/0x430 >>> [ 67.894444] uevent_show+0x176/0x1b0 >>> [ 67.896709] dev_attr_show+0x37/0x70 >>> [ 67.898940] sysfs_kf_seq_show+0x119/0x210 >>> [ 67.901159] seq_read+0x29d/0x720 >>> [ 67.903367] vfs_read+0xf9/0x1f0 >>> [ 67.905538] ksys_read+0xc9/0x160 >>> [ 67.907736] do_syscall_64+0x74/0xd0 >>> [ 67.909889] entry_SYSCALL_64_after_hwframe+0x49/0xbe >>> >>> [ 67.914100] The buggy address belongs to the object at >>> ffff88870afe8000 >>> which belongs to the cache kmalloc-4k of size 4096 >>> [ 67.918357] The buggy address is located 2344 bytes inside of >>> 4096-byte region [ffff88870afe8000, ffff88870afe9000) >>> [ 67.922562] The buggy address belongs to the page: >>> [ 67.924725] page:ffffea001c2bfa00 refcount:1 mapcount:0 >>> mapping:ffff88881f00de00 index:0x0 compound_mapcount: 0 >>> [ 67.926926] raw: 0017ffe000010200 ffffea001c167a00 >>> 0000000200000002 ffff88881f00de00 >>> [ 67.929144] raw: 0000000000000000 0000000080040004 >>> 00000001ffffffff 0000000000000000 >>> [ 67.931362] page dumped because: kasan: bad access detected >>> >>> [ 67.936192] Memory state around the buggy address: >>> [ 67.938438] ffff88870afe8800: 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 >>> [ 67.941078] ffff88870afe8880: fc fc fc fc fc fc fc fc fc fc fc fc >>> fc fc fc fc >>> [ 67.943393] >ffff88870afe8900: fc fc fc fc fc fc fc fc fc fc fc fc >>> fc fc fc fc >>> [ 67.945709] ^ >>> [ 67.948000] ffff88870afe8980: fc fc fc fc fc fc fc fc fc fc fc fc >>> fc fc fc fc >>> [ 67.950311] ffff88870afe8a00: fc fc fc fc fc fc fc fc fc fc fc fc >>> fc fc fc fc >>> [ 67.952629] >>> ================================================================== >
On 1/27/2020 8:14 AM, Stephen Smalley wrote: > On 1/24/20 4:49 PM, Casey Schaufler wrote: >> On 1/24/2020 1:04 PM, Stephen Smalley wrote: >>> On 1/23/20 7:22 PM, Casey Schaufler wrote: >>>> This patchset provides the changes required for >>>> the AppArmor security module to stack safely with any other. >>>> >>>> v14: Rebase to 5.5-rc5 >>>> Incorporate feedback from v13 >>>> - Use an array of audit rules (patch 0002) >>>> - Significant change, removed Acks (patch 0002) >>>> - Remove unneeded include (patch 0013) >>>> - Use context.len correctly (patch 0015) >>>> - Reorder code to be more sensible (patch 0016) >>>> - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) >>> >>> I don't know for sure if this is your bug, but it happens every time I boot with your patches applied and not at all on stock v5.5-rc5 so here it is. Will try to bisect as time permits but not until next week. Trigger seems to be loading the tun driver. >> >> Thanks. I will have a look as well. > > Bisection led to the first patch in the series, "LSM: Infrastructure management of the sock security". Still not sure if the bug is in the patch itself or just being surfaced by it. It looks like the tun code is making a private socket in tun_chr_open() without initializing the sk_security member. It's possible that this used to work implicitly, but I don't see how the change should have broken that. Investigation continues.
On 1/27/2020 8:56 AM, Stephen Smalley wrote: > On 1/27/20 11:14 AM, Stephen Smalley wrote: >> On 1/24/20 4:49 PM, Casey Schaufler wrote: >>> On 1/24/2020 1:04 PM, Stephen Smalley wrote: >>>> On 1/23/20 7:22 PM, Casey Schaufler wrote: >>>>> This patchset provides the changes required for >>>>> the AppArmor security module to stack safely with any other. >>>>> >>>>> v14: Rebase to 5.5-rc5 >>>>> Incorporate feedback from v13 >>>>> - Use an array of audit rules (patch 0002) >>>>> - Significant change, removed Acks (patch 0002) >>>>> - Remove unneeded include (patch 0013) >>>>> - Use context.len correctly (patch 0015) >>>>> - Reorder code to be more sensible (patch 0016) >>>>> - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) >>>> >>>> I don't know for sure if this is your bug, but it happens every time I boot with your patches applied and not at all on stock v5.5-rc5 so here it is. Will try to bisect as time permits but not until next week. Trigger seems to be loading the tun driver. >>> >>> Thanks. I will have a look as well. >> >> Bisection led to the first patch in the series, "LSM: Infrastructure management of the sock security". Still not sure if the bug is in the patch itself or just being surfaced by it. > > Looks like the bug is pre-existing to me and just exposed by your patch. OK, thanks. I don't see how moving the allocation ought to have perturbed that, but it's good to know what happened.
This patchset provides the changes required for the AppArmor security module to stack safely with any other. v14: Rebase to 5.5-rc5 Incorporate feedback from v13 - Use an array of audit rules (patch 0002) - Significant change, removed Acks (patch 0002) - Remove unneeded include (patch 0013) - Use context.len correctly (patch 0015) - Reorder code to be more sensible (patch 0016) - Drop SO_PEERCONTEXT as it's not needed yet (patch 0023) v13: Rebase to 5.5-rc2 Incorporate feedback from v12 - Print lsmblob size with %z (Patch 0002) - Convert lockdown LSM initialization. (Patch 0002) - Restore error check in nft_secmark_compute_secid (Patch 0006) - Correct blob scaffolding in ima_must_appraise() (Patch 0009) - Make security_setprocattr() clearer (Patch 0013) - Use lsm_task_display more widely (Patch 0013) - Use passed size in lsmcontext_init() (Patch 0014) - Don't add a smack_release_secctx() hook (Patch 0014) - Don't print warning in security_release_secctx() (Patch 0014) - Don't duplicate the label in nfs4_label_init_security() (Patch 0016) - Remove reviewed-by as code has significant change (Patch 0016) - Send the entire lsmblob for Tag 6 (Patch 0019) - Fix description of socket_getpeersec_stream parameters (Patch 0023) - Retain LSMBLOB_FIRST. What was I thinking? (Patch 0023) - Add compound context to LSM documentation (Patch 0023) v12: Rebase to 5.5-rc1 Fixed a couple of incorrect contractions in the text. v11: Rebase to 5.4-rc6 Incorporate feedback from v10 - Disambiguate reading /proc/.../attr/display by restricting all use of the interface to the current process. - Fix a merge error in AppArmor's display attribute check v10: Ask the security modules if the display can be changed. v9: There is no version 9 v8: Incorporate feedback from v7 - Minor clean-up in display value management - refactor "compound" context creation to use a common append_ctx() function. v7: Incorporate feedback from v6 - Make setting the display a privileged operation. The availability of compound contexts reduces the need for setting the display. v6: Incorporate feedback from v5 - Add subj_<lsm>= and obj_<lsm>= fields to audit records - Add /proc/.../attr/context to get the full context in lsmname\0value\0... format as suggested by Simon McVittie - Add SO_PEERCONTEXT for getsockopt() to get the full context in the same format, also suggested by Simon McVittie. - Add /sys/kernel/security/lsm_display_default to provide the display default value. v5: Incorporate feedback from v4 - Initialize the lsmcontext in security_secid_to_secctx() - Clear the lsmcontext in all security_release_secctx() cases - Don't use the "display" on strictly internal context interfaces. - The SELinux binder hooks check for cases where the context "display" isn't compatible with SELinux. v4: Incorporate feedback from v3 - Mark new lsm_<blob>_alloc functions static - Replace the lsm and slot fields of the security_hook_list with a pointer to a LSM allocated lsm_id structure. The LSM identifies if it needs a slot explicitly. Use the lsm_id rather than make security_add_hooks return the slot value. - Validate slot values used in security.c - Reworked the "display" process attribute handling so that it works right and doesn't use goofy list processing. - fix display value check in dentry_init_security - Replace audit_log of secids with '?' instead of deleting the audit log v3: Incorporate feedback from v2 - Make lsmblob parameter and variable names more meaningful, changing "le" and "l" to "blob". - Improve consistency of constant naming. - Do more sanity checking during LSM initialization. - Be a bit clearer about what is temporary scaffolding. - Rather than clutter security_getpeersec_dgram with otherwise unnecessary checks remove the apparmor stub, which does nothing useful. Patch 0001 moves management of the sock security blob from the individual modules to the infrastructure. Patches 0002-0012 replace system use of a "secid" with a structure "lsmblob" containing information from the security modules to be held and reused later. At this point lsmblob contains an array of u32 secids, one "slot" for each of the security modules compiled into the kernel that used secids. A "slot" is allocated when a security module requests one. The infrastructure is changed to use the slot number to pass the correct secid to or from the security module hooks. It is important that the lsmblob be a fixed size entity that does not have to be allocated. Several of the places where it is used would have performance and/or locking issues with dynamic allocation. Patch 0013 provides a mechanism for a process to identify which security module's hooks should be used when displaying or converting a security context string. A new interface /proc/self/attr/display contains the name of the security module to show. Reading from this file will present the name of the module, while writing to it will set the value. Only names of active security modules are accepted. Internally, the name is translated to the appropriate "slot" number for the module which is then stored in the task security blob. Setting the display requires that all modules using the /proc interfaces allow the transition. The "display" of other processess can be neither read nor written. All suggested cases for reading the display of a different process have race conditions. Patch 0014 Starts the process of changing how a security context is represented. Since it is possible for a security context to have been generated by more than one security module it is now necessary to note which module created a security context so that the correct "release" hook can be called. There are several places where the module that created a security context cannot be inferred. This is achieved by introducing a "lsmcontext" structure which contains the context string, its length and the "slot" number of the security module that created it. The security_release_secctx() interface is changed, replacing the (string,len) pointer pair with a lsmcontext pointer. Patches 0015-0017 convert the security interfaces from (string,len) pointer pairs to a lsmcontext pointer. The slot number identifying the creating module is added by the infrastructure. Where the security context is stored for extended periods the data type is changed. The Netlabel code is converted to save lsmblob structures instead of secids in Patch 0018. Patch 0019 adds checks to the binder hooks which verify that if both ends of a transaction use the same "display". Patches 0020-0021 add addition data to the audit records to identify the LSM specific data for all active modules. Patch 0022 adds a new interfaces for getting the compound security contexts. Finally, with all interference on the AppArmor hooks removed, Patch 0023 removes the exclusive bit from AppArmor. An unnecessary stub hook was also removed. The Ubuntu project is using an earlier version of this patchset in their distribution to enable stacking for containers. Performance measurements to date have the change within the "noise". The sockperf and dbench results are on the order of 0.2% to 0.8% difference, with better performance being as common as worse. The benchmarks were run with AppArmor and Smack on Ubuntu. https://github.com/cschaufler/lsm-stacking.git#stack-5.5-rc5-v14 Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> ---