RFE: log the policy capability state when a new policy is loaded into the kernel #32

pcmoore · 2017-05-09T17:45:18Z

We should record if the known policy capabilities are enabled/disabled by the newly loaded SELinux policy. We may also want to record any unknown policy capabilities for informative purposes.

stephensmalley · 2017-05-19T15:21:05Z

Resolved by 21d34af

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: #32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>

Commit a47b70e ("ravb: unmap descriptors when freeing rings") has introduced the issue seen in [1] reproduced on H3ULCB board. Fix this by relocating the RX skb ringbuffer free operation, so that swiotlb page unmapping can be done first. Freeing of aligned TX buffers is not relevant to the issue seen in [1]. Still, reposition TX free calls as well, to have all kfree() operations performed consistently _after_ dma_unmap_*()/dma_free_*(). [1] Console screenshot with the problem reproduced: salvator-x login: root root@salvator-x:~# ifconfig eth0 up Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: \ attached PHY driver [Micrel KSZ9031 Gigabit PHY] \ (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=235) IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready root@salvator-x:~# root@salvator-x:~# ifconfig eth0 down ================================================================== BUG: KASAN: use-after-free in swiotlb_tbl_unmap_single+0xc4/0x35c Write of size 1538 at addr ffff8006d884f780 by task ifconfig/1649 CPU: 0 PID: 1649 Comm: ifconfig Not tainted 4.12.0-rc4-00004-g112eb07287d1 #32 Hardware name: Renesas H3ULCB board based on r8a7795 (DT) Call trace: [<ffff20000808f11c>] dump_backtrace+0x0/0x3a4 [<ffff20000808f4d4>] show_stack+0x14/0x1c [<ffff20000865970c>] dump_stack+0xf8/0x150 [<ffff20000831f8b0>] print_address_description+0x7c/0x330 [<ffff200008320010>] kasan_report+0x2e0/0x2f4 [<ffff20000831eac0>] check_memory_region+0x20/0x14c [<ffff20000831f054>] memcpy+0x48/0x68 [<ffff20000869ed50>] swiotlb_tbl_unmap_single+0xc4/0x35c [<ffff20000869fcf4>] unmap_single+0x90/0xa4 [<ffff20000869fd14>] swiotlb_unmap_page+0xc/0x14 [<ffff2000080a2974>] __swiotlb_unmap_page+0xcc/0xe4 [<ffff2000088acdb8>] ravb_ring_free+0x514/0x870 [<ffff2000088b25dc>] ravb_close+0x288/0x36c [<ffff200008aaf8c4>] __dev_close_many+0x14c/0x174 [<ffff200008aaf9b4>] __dev_close+0xc8/0x144 [<ffff200008ac2100>] __dev_change_flags+0xd8/0x194 [<ffff200008ac221c>] dev_change_flags+0x60/0xb0 [<ffff200008ba2dec>] devinet_ioctl+0x484/0x9d4 [<ffff200008ba7b78>] inet_ioctl+0x190/0x194 [<ffff200008a78c44>] sock_do_ioctl+0x78/0xa8 [<ffff200008a7a128>] sock_ioctl+0x110/0x3c4 [<ffff200008365a70>] vfs_ioctl+0x90/0xa0 [<ffff200008365dbc>] do_vfs_ioctl+0x148/0xc38 [<ffff2000083668f0>] SyS_ioctl+0x44/0x74 [<ffff200008083770>] el0_svc_naked+0x24/0x28 The buggy address belongs to the page: page:ffff7e001b6213c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: 0000000000000000 ffff7e001b6213e0 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8006d884f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8006d884f700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff8006d884f780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff8006d884f800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8006d884f880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint root@salvator-x:~# Fixes: a47b70e ("ravb: unmap descriptors when freeing rings") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>

syszkaller reported use-after-free in tipc [1] When msg->rep skb is freed, set the pointer to NULL, so that caller does not free it again. [1] ================================================================== BUG: KASAN: use-after-free in skb_push+0xd4/0xe0 net/core/skbuff.c:1466 Read of size 8 at addr ffff8801c6e71e90 by task syz-executor5/4115 CPU: 1 PID: 4115 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #32 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:52 print_address_description+0x73/0x250 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x24e/0x340 mm/kasan/report.c:409 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430 skb_push+0xd4/0xe0 net/core/skbuff.c:1466 tipc_nl_compat_recv+0x833/0x18f0 net/tipc/netlink_compat.c:1209 genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397 genl_rcv+0x28/0x40 net/netlink/genetlink.c:634 netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline] netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291 netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 sock_write_iter+0x31a/0x5d0 net/socket.c:898 call_write_iter include/linux/fs.h:1743 [inline] new_sync_write fs/read_write.c:457 [inline] __vfs_write+0x684/0x970 fs/read_write.c:470 vfs_write+0x189/0x510 fs/read_write.c:518 SYSC_write fs/read_write.c:565 [inline] SyS_write+0xef/0x220 fs/read_write.c:557 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4512e9 RSP: 002b:00007f3bc8184c08 EFLAGS: 00000216 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004512e9 RDX: 0000000000000020 RSI: 0000000020fdb000 RDI: 0000000000000006 RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004b5e76 R13: 00007f3bc8184b48 R14: 00000000004b5e86 R15: 0000000000000000 Allocated by task 4115: save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489 kmem_cache_alloc_node+0x13d/0x750 mm/slab.c:3651 __alloc_skb+0xf1/0x740 net/core/skbuff.c:219 alloc_skb include/linux/skbuff.h:903 [inline] tipc_tlv_alloc+0x26/0xb0 net/tipc/netlink_compat.c:148 tipc_nl_compat_dumpit+0xf2/0x3c0 net/tipc/netlink_compat.c:248 tipc_nl_compat_handle net/tipc/netlink_compat.c:1130 [inline] tipc_nl_compat_recv+0x756/0x18f0 net/tipc/netlink_compat.c:1199 genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397 genl_rcv+0x28/0x40 net/netlink/genetlink.c:634 netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline] netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291 netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 sock_write_iter+0x31a/0x5d0 net/socket.c:898 call_write_iter include/linux/fs.h:1743 [inline] new_sync_write fs/read_write.c:457 [inline] __vfs_write+0x684/0x970 fs/read_write.c:470 vfs_write+0x189/0x510 fs/read_write.c:518 SYSC_write fs/read_write.c:565 [inline] SyS_write+0xef/0x220 fs/read_write.c:557 entry_SYSCALL_64_fastpath+0x1f/0xbe Freed by task 4115: save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524 __cache_free mm/slab.c:3503 [inline] kmem_cache_free+0x77/0x280 mm/slab.c:3763 kfree_skbmem+0x1a1/0x1d0 net/core/skbuff.c:622 __kfree_skb net/core/skbuff.c:682 [inline] kfree_skb+0x165/0x4c0 net/core/skbuff.c:699 tipc_nl_compat_dumpit+0x36a/0x3c0 net/tipc/netlink_compat.c:260 tipc_nl_compat_handle net/tipc/netlink_compat.c:1130 [inline] tipc_nl_compat_recv+0x756/0x18f0 net/tipc/netlink_compat.c:1199 genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:598 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:623 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2397 genl_rcv+0x28/0x40 net/netlink/genetlink.c:634 netlink_unicast_kernel net/netlink/af_netlink.c:1265 [inline] netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1291 netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1854 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 sock_write_iter+0x31a/0x5d0 net/socket.c:898 call_write_iter include/linux/fs.h:1743 [inline] new_sync_write fs/read_write.c:457 [inline] __vfs_write+0x684/0x970 fs/read_write.c:470 vfs_write+0x189/0x510 fs/read_write.c:518 SYSC_write fs/read_write.c:565 [inline] SyS_write+0xef/0x220 fs/read_write.c:557 entry_SYSCALL_64_fastpath+0x1f/0xbe The buggy address belongs to the object at ffff8801c6e71dc0 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 208 bytes inside of 224-byte region [ffff8801c6e71dc0, ffff8801c6e71ea0) The buggy address belongs to the page: page:ffffea00071b9c40 count:1 mapcount:0 mapping:ffff8801c6e71000 index:0x0 flags: 0x200000000000100(slab) raw: 0200000000000100 ffff8801c6e71000 0000000000000000 000000010000000c raw: ffffea0007224a20 ffff8801d98caf48 ffff8801d9e79040 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801c6e71d80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8801c6e71e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801c6e71e80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8801c6e71f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801c6e71f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Jon Maloy <jon.maloy@ericsson.com> Cc: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Twisted <36546624+TwistedPrime@users.noreply.github.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: fadlyas07 <fadlyardhians@gmail.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Twisted <36546624+TwistedPrime@users.noreply.github.com> Signed-off-by: MadeOfGreat <ravenklawasd@gmail.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Twisted <36546624+TwistedPrime@users.noreply.github.com> Signed-off-by: MadeOfGreat <ravenklawasd@gmail.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>

Log the state of SELinux policy capabilities when a policy is loaded. For each policy capability known to the kernel, log the policy capability name and the value set in the policy. For policy capabilities that are set in the loaded policy but unknown to the kernel, log the policy capability index, since this is the only information presently available in the policy. Sample output with a policy created with a new capability defined that is not known to the kernel: SELinux: policy capability network_peer_controls=1 SELinux: policy capability open_perms=1 SELinux: policy capability extended_socket_class=1 SELinux: policy capability always_check_network=0 SELinux: policy capability cgroup_seclabel=0 SELinux: unknown policy capability 5 Resolves: SELinuxProject/selinux-kernel#32 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com> (cherry picked from commit 4dc2fce342f8e5b165e2eda29a39446bb07b2457) Resolved conflicts with extended_socket_class and cgroup_seclabel policy capabilities. These are referred to as "compat1" and "compat2" in the change to preserve compatibility with the policy binary. Neither of these policy capabilities are appropriate for backporting as they will break Treble backwards-compat requirements. Change-Id: Ic1c37514b742829904e3c9536a865f29150658ce Bug: 140252993 Signed-off-by: Jeff Vander Stoep <jeffv@google.com> Signed-off-by: Rapherion Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>

With BPF_PROBE_MEM, BPF allows de-referencing an untrusted pointer. To thwart invalid memory accesses, the JITs add an exception table entry for all such accesses. But in case the src_reg + offset is a userspace address, the BPF program might read that memory if the user has mapped it. Make the verifier add guard instructions around such memory accesses and skip the load if the address falls into the userspace region. The JITs need to implement bpf_arch_uaddress_limit() to define where the userspace addresses end for that architecture or TASK_SIZE is taken as default. The implementation is as follows: REG_AX = SRC_REG if(offset) REG_AX += offset; REG_AX >>= 32; if (REG_AX <= (uaddress_limit >> 32)) DST_REG = 0; else DST_REG = *(size *)(SRC_REG + offset); Comparing just the upper 32 bits of the load address with the upper 32 bits of uaddress_limit implies that the values are being aligned down to a 4GB boundary before comparison. The above means that all loads with address <= uaddress_limit + 4GB are skipped. This is acceptable because there is a large hole (much larger than 4GB) between userspace and kernel space memory, therefore a correctly functioning BPF program should not access this 4GB memory above the userspace. Let's analyze what this patch does to the following fentry program dereferencing an untrusted pointer: SEC("fentry/tcp_v4_connect") int BPF_PROG(fentry_tcp_v4_connect, struct sock *sk) { *(volatile long *)sk; return 0; } BPF Program before | BPF Program after ------------------ | ----------------- 0: (79) r1 = *(u64 *)(r1 +0) 0: (79) r1 = *(u64 *)(r1 +0) ----------------------------------------------------------------------- 1: (79) r1 = *(u64 *)(r1 +0) --\ 1: (bf) r11 = r1 ----------------------------\ \ 2: (77) r11 >>= 32 2: (b7) r0 = 0 \ \ 3: (b5) if r11 <= 0x8000 goto pc+2 3: (95) exit \ \-> 4: (79) r1 = *(u64 *)(r1 +0) \ 5: (05) goto pc+1 \ 6: (b7) r1 = 0 \-------------------------------------- 7: (b7) r0 = 0 8: (95) exit As you can see from above, in the best case (off=0), 5 extra instructions are emitted. Now, we analyze the same program after it has gone through the JITs of ARM64 and RISC-V architectures. We follow the single load instruction that has the untrusted pointer and see what instrumentation has been added around it. x86-64 JIT ========== JIT's Instrumentation (upstream) --------------------- 0: nopl 0x0(%rax,%rax,1) 5: xchg %ax,%ax 7: push %rbp 8: mov %rsp,%rbp b: mov 0x0(%rdi),%rdi --------------------------------- f: movabs $0x800000000000,%r11 19: cmp %r11,%rdi 1c: jb 0x000000000000002a 1e: mov %rdi,%r11 21: add $0x0,%r11 28: jae 0x000000000000002e 2a: xor %edi,%edi 2c: jmp 0x0000000000000032 2e: mov 0x0(%rdi),%rdi --------------------------------- 32: xor %eax,%eax 34: leave 35: ret The x86-64 JIT already emits some instructions to protect against user memory access. This patch doesn't make any changes for the x86-64 JIT. ARM64 JIT ========= No Intrumentation Verifier's Instrumentation (upstream) (This patch) ----------------- -------------------------- 0: add x9, x30, #0x0 0: add x9, x30, #0x0 4: nop 4: nop 8: paciasp 8: paciasp c: stp x29, x30, [sp, #-16]! c: stp x29, x30, [sp, #-16]! 10: mov x29, sp 10: mov x29, sp 14: stp x19, x20, [sp, #-16]! 14: stp x19, x20, [sp, #-16]! 18: stp x21, x22, [sp, #-16]! 18: stp x21, x22, [sp, #-16]! 1c: stp x25, x26, [sp, #-16]! 1c: stp x25, x26, [sp, #-16]! 20: stp x27, x28, [sp, #-16]! 20: stp x27, x28, [sp, #-16]! 24: mov x25, sp 24: mov x25, sp 28: mov x26, #0x0 28: mov x26, #0x0 2c: sub x27, x25, #0x0 2c: sub x27, x25, #0x0 30: sub sp, sp, #0x0 30: sub sp, sp, #0x0 34: ldr x0, [x0] 34: ldr x0, [x0] -------------------------------------------------------------------------------- 38: ldr x0, [x0] ----------\ 38: add x9, x0, #0x0 -----------------------------------\\ 3c: lsr x9, x9, SELinuxProject#32 3c: mov x7, #0x0 \\ 40: cmp x9, #0x10, lsl SELinuxProject#12 40: mov sp, sp \\ 44: b.ls 0x0000000000000050 44: ldp x27, x28, [sp], SELinuxProject#16 \\--> 48: ldr x0, [x0] 48: ldp x25, x26, [sp], SELinuxProject#16 \ 4c: b 0x0000000000000054 4c: ldp x21, x22, [sp], SELinuxProject#16 \ 50: mov x0, #0x0 50: ldp x19, x20, [sp], SELinuxProject#16 \--------------------------------------- 54: ldp x29, x30, [sp], SELinuxProject#16 54: mov x7, #0x0 58: add x0, x7, #0x0 58: mov sp, sp 5c: autiasp 5c: ldp x27, x28, [sp], SELinuxProject#16 60: ret 60: ldp x25, x26, [sp], SELinuxProject#16 64: nop 64: ldp x21, x22, [sp], SELinuxProject#16 68: ldr x10, 0x0000000000000070 68: ldp x19, x20, [sp], SELinuxProject#16 6c: br x10 6c: ldp x29, x30, [sp], SELinuxProject#16 70: add x0, x7, #0x0 74: autiasp 78: ret 7c: nop 80: ldr x10, 0x0000000000000088 84: br x10 There are 6 extra instructions added in ARM64 in the best case. This will become 7 in the worst case (off != 0). RISC-V JIT (RISCV_ISA_C Disabled) ========== No Intrumentation Verifier's Instrumentation (upstream) (This patch) ----------------- -------------------------- 0: nop 0: nop 4: nop 4: nop 8: li a6, 33 8: li a6, 33 c: addi sp, sp, -16 c: addi sp, sp, -16 10: sd s0, 8(sp) 10: sd s0, 8(sp) 14: addi s0, sp, 16 14: addi s0, sp, 16 18: ld a0, 0(a0) 18: ld a0, 0(a0) --------------------------------------------------------------- 1c: ld a0, 0(a0) --\ 1c: mv t0, a0 --------------------------\ \ 20: srli t0, t0, 32 20: li a5, 0 \ \ 24: lui t1, 4096 24: ld s0, 8(sp) \ \ 28: sext.w t1, t1 28: addi sp, sp, 16 \ \ 2c: bgeu t1, t0, 12 2c: sext.w a0, a5 \ \--> 30: ld a0, 0(a0) 30: ret \ 34: j 8 \ 38: li a0, 0 \------------------------------ 3c: li a5, 0 40: ld s0, 8(sp) 44: addi sp, sp, 16 48: sext.w a0, a5 4c: ret There are 7 extra instructions added in RISC-V. Fixes: 8008342 ("bpf, arm64: Add BPF exception tables") Reported-by: Breno Leitao <leitao@debian.org> Suggested-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20240424100210.11982-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>