{"id":1275,"date":"2019-05-27T20:49:22","date_gmt":"2019-05-28T03:49:22","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1275"},"modified":"2022-04-04T14:34:43","modified_gmt":"2022-04-04T21:34:43","slug":"security-things-in-linux-v5-1","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2019\/05\/27\/security-things-in-linux-v5-1\/","title":{"rendered":"security things in Linux v5.1"},"content":{"rendered":"

Previously: v5.0<\/a>.<\/p>\n

Linux kernel v5.1 has been released<\/a>! Here are some security-related things that stood out to me:<\/p>\n

introduction of pidfd<\/strong>
\nChristian Brauner landed the first portion of his work to remove pid races from the kernel: using a file descriptor to reference a process<\/a> (“pidfd”). Now \/proc\/$pid<\/code> can be opened and used as an argument for sending signals with the new pidfd_send_signal()<\/code> syscall. This handle will only refer to the original process at the time the open()<\/code> happened, and not to any later “reused” pid if the process dies and a new process is assigned the same pid. Using this method, it’s now possible to racelessly send signals to exactly the intended process without having to worry about pid reuse. (BTW, this commit wins the 2019 award for Most Well Documented Commit Log Justification.)<\/p>\n

explicitly test for userspace mappings of heap memory<\/strong>
\nDuring Linux Conf AU 2019 Kernel Hardening BoF<\/a>, Matthew Wilcox noted that there wasn’t anything in the kernel actually sanity-checking when userspace mappings were being applied to kernel heap memory (which would allow attackers to bypass the copy_{to,from}_user()<\/code> infrastructure). Driver bugs or attackers able to confuse mappings wouldn’t get caught, so he added checks. To quote the commit logs: “It’s never appropriate to map a page allocated by SLAB into userspace”<\/a> and “Pages which use page_type must never be mapped to userspace as it would destroy their page type”<\/a>. The latter check almost immediately caught a bad case<\/a>, which was quickly fixed<\/a> to avoid page type corruption.<\/p>\n

LSM stacking: shared security blobs<\/strong>
\nCasey Schaufler has landed one of the major pieces of getting multiple Linux Security Modules (LSMs) running at the same time (called “stacking”). It is now possible for LSMs to share the security-specific storage “blobs”<\/a> associated with various core structures (e.g. inodes, tasks, etc) that LSMs can use for saving their state (e.g. storing which profile a given task confined under). The kernel originally gave only the single active “major” LSM (e.g. SELinux, Apprmor, etc) full control over the entire blob of storage. With “shared” security blobs, the LSM infrastructure does the allocation and management of the memory, and LSMs use an offset for reading\/writing their portion of it. This unblocks the way for “medium sized” LSMs (like SARA<\/a> and Landlock<\/a>) to get stacked with a “major” LSM as they need to store much more state than the “minor” LSMs (e.g. Yama, LoadPin) which could already stack because they didn’t need blob storage.<\/p>\n

SafeSetID LSM<\/strong>
\nMicah Morton added<\/a> the new SafeSetID LSM<\/a>, which provides a way to narrow the power associated with the CAP_SETUID<\/code> capability. Normally a process with CAP_SETUID<\/code> can become any user on the system, including root, which makes it a meaningless capability to hand out to non-root users in order for them to “drop privileges” to some less powerful user. There are trees of processes under Chrome OS that need to operate under different user IDs and other methods of accomplishing these transitions safely weren’t sufficient. Instead, this provides a way to create a system-wide policy for user ID transitions via setuid()<\/code> (and group transitions via setgid()<\/code>) when a process has the CAP_SETUID<\/code> capability, making it a much more useful capability to hand out to non-root processes that need to make uid or gid transitions.<\/p>\n

ongoing: refcount_t conversions<\/strong>
\nElena Reshetova continued landing<\/a> more refcount_t<\/code> conversions<\/a><\/a> in core kernel code (e.g. scheduler, futex, perf), with an additional conversion in btrfs from Anand Jain. The existing conversions, mainly when combined with syzkaller, continue to show their utility at finding<\/a> bugs<\/a> all<\/a> over<\/a> the kernel.<\/p>\n

ongoing: implicit fall-through removal<\/strong>
\nGustavo A. R. Silva continued to make progress on marking<\/a> more implicit fall-through<\/a> cases. What’s so impressive to me about this work, like refcount_t<\/code>, is how many bugs it has been finding (see all the “missing break<\/a>” patches). It really shows how quickly the kernel benefits from adding -Wimplicit-fallthrough<\/code> to keep this class of bug from ever returning.<\/p>\n

stack variable initialization includes scalars<\/strong>
\nThe structleak gcc plugin (originally ported from PaX<\/a>) had its “by reference” coverage<\/a> improved to initialize scalar types<\/a> as well (making “structleak” a bit of a misnomer: it now stops leaks from more than structs). Barring compiler bugs, this means that all stack variables in the kernel can be initialized before use at function entry. For variables not passed to functions by reference, the -Wuninitialized<\/code> compiler flag (enabled via -Wall<\/code>) already makes sure the kernel isn’t building with local-only uninitialized stack variables. And now with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL<\/code> enabled, all variables passed by reference will be initialized as well. This should eliminate most, if not all, uninitialized stack flaws with very minimal performance cost (for most workloads it is lost in the noise), though it does not have the stack data lifetime reduction benefits of GCC_PLUGIN_STACKLEAK<\/code><\/a>, which wipes the stack at syscall exit. Clang has recently gained similar automatic stack initialization support<\/a>, and I’d love to this feature in native gcc. To evaluate the coverage of the various stack auto-initialization features, I also wrote regression tests in lib\/test_stackinit.c<\/a>.<\/p>\n

That’s it for now; please let me know if I missed anything. The v5.2<\/a> kernel development cycle is off and running already. :)<\/p>\n

© 2019 – 2022, Kees Cook<\/a>. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License<\/a>.
\"CC<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"

Previously: v5.0. Linux kernel v5.1 has been released! Here are some security-related things that stood out to me: introduction of pidfd Christian Brauner landed the first portion of his work to remove pid races from the kernel: using a file descriptor to reference a process (“pidfd”). Now \/proc\/$pid can be opened and used as an […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1275"}],"collection":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/comments?post=1275"}],"version-history":[{"count":29,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1275\/revisions"}],"predecessor-version":[{"id":1572,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/1275\/revisions\/1572"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=1275"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=1275"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=1275"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}