{"id":1406,"date":"2020-05-27T13:04:24","date_gmt":"2020-05-27T20:04:24","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=1406"},"modified":"2020-09-02T16:23:18","modified_gmt":"2020-09-02T23:23:18","slug":"security-things-in-linux-v5-5","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2020\/05\/27\/security-things-in-linux-v5-5\/","title":{"rendered":"security things in Linux v5.5"},"content":{"rendered":"

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

I got a bit behind on this blog post series! Let’s get caught up. Here are a bunch of security things I found interesting in the Linux kernel v5.5 release<\/a>:<\/p>\n

restrict perf_event_open()<\/code> from LSM<\/strong>
\nGiven the recurring flaws in the perf subsystem, there has been a strong desire to be able to entirely disable the interface. While the kernel.perf_event_paranoid<\/code> sysctl knob has existed for a while, attempts to extend its control to “block all perf_event_open()<\/code> calls” have failed in the past<\/a>. Distribution kernels have carried the rejected sysctl patch for many years, but now Joel Fernandes has implemented a solution that was deemed acceptable: instead of extending the sysctl, add LSM hooks<\/a> so that LSMs (e.g. SELinux, Apparmor, etc) can make these choices as part of their overall system policy.<\/p>\n

generic fast full refcount_t<\/code><\/strong>
\nWill Deacon took the recent refcount_t<\/code> hardening work for both x86 and arm64 and distilled the implementations into a single architecture-agnostic C version<\/a>. The result was almost as fast as the x86 assembly version, but it covered more cases (e.g. increment-from-zero), and is now available by default for all architectures<\/a>. (There is no longer any Kconfig associated with refcount_t<\/code>; the use of the primitive provides full coverage.)<\/p>\n

linker script cleanup for exception tables<\/strong>
\nWhen Rick Edgecombe presented<\/a> his work on building Execute-Only memory under a hypervisor<\/a>, he noted a region of memory that the kernel was attempting to read directly (instead of execute). He rearranged things for his x86-only patch series to work around<\/a> the issue. Since I’d just been working in this area, I realized the root cause of this problem was the location of the exception table (which is strictly a lookup table and is never executed) and built a fix for the issue<\/a> and applied it to all architectures<\/a>, since it turns out the exception tables for almost all architectures are just a data table. Hopefully this will help clear the path for more Execute-Only memory work on all architectures. In the process of this, I also updated the section fill bytes on x86 to be a trap<\/a> (0xCC, int3), instead of a NOP instruction so functions would need to be targeted more precisely by attacks.<\/p>\n

KASLR for 32-bit PowerPC<\/strong>
\nJoining many other architectures, Jason Yan added kernel text base-address offset randomization (KASLR) to 32-bit PowerPC<\/a>.<\/p>\n

seccomp for RISC-V<\/strong>
\nAfter a bit of long road, David Abdurachmanov has added seccomp support to the RISC-V architecture<\/a>. The series uncovered some more corner cases in the seccomp self tests code, which is always nice since then we get to make it more robust for the future!<\/p>\n

seccomp USER_NOTIF<\/code> continuation<\/strong>
\nWhen the seccomp SECCOMP_RET_USER_NOTIF<\/code> interface<\/a> was added, it seemed like it would only be used in very limited conditions, so the idea of needing to handle “normal” requests didn’t seem very onerous. However, since then, it has become clear that the overhead of a monitor process needing to perform lots of “normal” open()<\/code> calls on behalf of the monitored process started to look more and more slow and fragile. To deal with this, it became clear that there needed to be a way for the USER_NOTIF<\/code> interface to indicate that seccomp should just continue as normal and allow the syscall without any special handling. Christian Brauner implemented SECCOMP_USER_NOTIF_FLAG_CONTINUE<\/code><\/a> to get this done. It comes with a bit of a disclaimer due to the chance that monitors may use it in places where ToCToU is a risk, and for possible conflicts with SECCOMP_RET_TRACE<\/code>. But overall, this is a net win for container monitoring tools.<\/p>\n

EFI_RNG_PROTOCOL<\/code> for x86<\/strong>
\nSome EFI systems provide a Random Number Generator interface, which is useful for gaining some entropy in the kernel during very early boot. The arm64 boot stub has been using this for a while now, but Dominik Brodowski has now added support for x86 to do the same<\/a>. This entropy is useful for kernel subsystems performing very earlier initialization whre random numbers are needed (like randomizing aspects of the SLUB memory allocator<\/a>).<\/p>\n

FORTIFY_SOURCE<\/code> for MIPS<\/strong>
\nAs has been enabled on many other architectures, Dmitry Korotin got MIPS building with CONFIG_FORTIFY_SOURCE<\/code><\/a>, so compile-time (and some run-time) buffer overflows during calls to the memcpy()<\/code> and strcpy()<\/code> families of functions will be detected<\/a>.<\/p>\n

limit copy_{to,from}_user()<\/code> size to INT_MAX<\/code><\/strong>
\nAs done for VFS, vsnprintf()<\/code>, and strscpy()<\/code><\/a>, I went ahead and limited the size<\/a> of copy_to_user()<\/code> and copy_from_user()<\/code> calls to INT_MAX<\/code> in order to catch any weird overflows in size calculations.<\/p>\n

Other things<\/strong>
\nAlexander Popov pointed out some more v5.5 features<\/a> that I missed in this blog post. I’m repeating them here, with some minor edits\/clarifications. Thank you Alexander!<\/p>\n