{"id":906,"date":"2016-09-28T13:58:00","date_gmt":"2016-09-28T21:58:00","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=906"},"modified":"2016-10-05T21:32:47","modified_gmt":"2016-10-06T04:32:47","slug":"security-things-in-linux-v4-5","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2016\/09\/28\/security-things-in-linux-v4-5\/","title":{"rendered":"security things in Linux v4.5"},"content":{"rendered":"

Previously: v4.4<\/a>. Some things I found interesting in the Linux kernel v4.5:<\/p>\n

CONFIG_IO_STRICT_DEVMEM<\/strong><\/p>\n

The CONFIG_STRICT_DEVMEM setting that has existed for a long time already protects system RAM from being accessible through the \/dev\/mem<\/code> device node to root in user-space. Dan Williams added CONFIG_IO_STRICT_DEVMEM<\/a> to extend this so that if a kernel driver has reserved a device memory region for use, it will become unavailable to \/dev\/mem<\/code> also. The reservation in the kernel was to keep other kernel things from using the memory, so this is just common sense to make sure user-space can’t stomp on it either. Everyone should have this enabled. (And if you have a system where you discover you need IO memory access from userspace, you can boot with “iomem=relaxed<\/code>” to disable this at runtime.)<\/p>\n

If you’re looking to create a very bright line between user-space having access to device memory, it’s worth noting that if a device driver is a module, a malicious root user can just unload the module (freeing the kernel memory reservation), fiddle with the device memory, and then reload the driver module. So either just leave out \/dev\/mem<\/code> entirely (not currently possible with upstream), build a monolithic kernel (no modules), or otherwise block (un)loading of modules<\/a> (\/proc\/sys\/kernel\/modules_disabled<\/code>).<\/p>\n

ptrace fsuid checking<\/strong><\/p>\n

Jann Horn fixed<\/a> some corner-cases in how ptrace access checks were handled on special files in \/proc<\/code>. For example, prior to this fix, if a setuid process temporarily dropped privileges to perform actions as a regular user, the ptrace checks would not notice the reduced privilege, possibly allowing a regular user to trick a privileged process into disclosing things out of \/proc<\/code> (ASLR offsets, restricted directories, etc) that they normally would be restricted from seeing.<\/p>\n

ASLR entropy sysctl<\/strong><\/p>\n

Daniel Cashman standardized the way architectures declare their maximum user-space ASLR entropy (CONFIG_ARCH_MMAP_RND_BITS_MAX) and then created a sysctl (\/proc\/sys\/vm\/mmap_rnd_bits<\/code>) so that system owners could crank up entropy. For example, the default entropy on 32-bit ARM was 8 bits, but the maximum could be as much as 16<\/a>. If your 64-bit kernel is built with CONFIG_COMPAT, there’s a compat version of the sysctl as well, for controlling the ASLR entropy of 32-bit processes: \/proc\/sys\/vm\/mmap_rnd_compat_bits<\/code>.<\/p>\n

Here’s how to crank your entropy to the max, without regard to what architecture you’re on:<\/p>\n

\r\nfor i in \"\" \"compat_\"; do f=\/proc\/sys\/vm\/mmap_rnd_${i}bits; n=$(cat $f); while echo $n > $f ; do n=$(( n + 1 )); done; done\r\n<\/pre>\n
strict sysctl writes<\/strong><\/p>\n
Two years ago I added a sysctl for treating sysctl writes more like regular files<\/a> (i.e. what’s written first is what appears at the start), rather than like a ring-buffer (what’s written last is what appears first). At the time it wasn’t clear what might break if this was enabled, so a WARN was added to the kernel. Since only one such string showed up in searches over the last two years, the strict writing mode was made the default<\/a>. The setting remains available as \/proc\/sys\/kernel\/sysctl_writes_strict<\/code>.<\/p>\n
seccomp UM support<\/strong><\/p>\n
Micka\u00ebl Sala\u00fcn added seccomp support<\/a> (and selftests) for user-mode Linux. Moar architectures!<\/p>\n
seccomp NNP vs TSYNC fix<\/strong><\/p>\n
Jann Horn noticed and fixed<\/a> a problem where if a seccomp filter was already in place on a process (after being installed by a privileged process like systemd, a container launcher, etc) then the setting of the “no new privs” flag could be bypassed when adding filters with the SECCOMP_FILTER_FLAG_TSYNC flag set. Bypassing NNP meant it might be possible to trick a buggy setuid program into doing things as root after a seccomp filter forced a privilege drop to fail (generally referred to as the “sendmail setuid flaw”). With NNP set, a setuid program can’t be run in the first place.<\/p>\n
That’s it! Next I’ll cover v4.6<\/a>…<\/p>\n
Edit: Added notes about “iomem=…”<\/p>\n
© 2016, 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: v4.4. Some things I found interesting in the Linux kernel v4.5: CONFIG_IO_STRICT_DEVMEM The CONFIG_STRICT_DEVMEM setting that has existed for a long time already protects system RAM from being accessible through the \/dev\/mem device node to root in user-space. Dan Williams added CONFIG_IO_STRICT_DEVMEM to extend this so that if a kernel driver has reserved a […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,18,21,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/906"}],"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=906"}],"version-history":[{"count":7,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/906\/revisions"}],"predecessor-version":[{"id":955,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/906\/revisions\/955"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}