lwn.net

The 5.6-rc3 kernel prepatch is out for testing. Linus says: "Fairly normal rc3 as far as I can tell. We've seen bigger, but we've seen smaller ones too. Maybe this is slightly on the low side of average at this time, which would make sense since this was a smaller merge window. Anyway, too much noise in the signal to be sure either way."

Stable kernels 5.5.6, 5.4.22, and 4.19.106 have been released. They all have a large set of important fixes.

Security updates have been issued by Debian (libpam-radius-auth, pillow, ppp, proftpd-dfsg, and python-pysaml2), Fedora (firefox, glib2, hiredis, http-parser, libuv, mingw-openjpeg2, nghttp2, nodejs, openjpeg2, python-pillow, skopeo, and webkit2gtk3), Mageia (patch, postgresql, and systemd), Red Hat (ksh, nodejs:10, openjpeg2, python-pillow, systemd, and thunderbird), and SUSE (java-1_7_1-ibm, libsolv, libzypp, zypper, pdsh, slurm_18_08, and php53).

The perf_event_open() system call is a complicated beast, requiring a fair amount of study to master. This call also has some interesting security implications: it can be used to obtain a lot of information about the running system, and the complexity of the underlying implementation has made it more than usually prone to unpleasant bugs. In current kernels, the security controls around perf_event_open() are simple, though: if you have the CAP_SYS_ADMIN capability, perf_event_open() is available to you (though the system administrator can make it available without any privilege at all). Some current work to create a new capability for the perf events subsystem would seem to make sense, raising the question of why adding new capabilities isn't done more often.

Security updates have been issued by CentOS (openjpeg2), Debian (cloud-init, jackson-databind, and python-reportlab), Red Hat (ksh, python-pillow, systemd, and thunderbird), Slackware (proftpd), SUSE (java-1_7_0-ibm, nodejs10, and nodejs12), and Ubuntu (ppp and squid, squid3).

To a great extent, memory management is based on making predictions: which pages of memory will a given process need in the near future? Unfortunately, it turns out that predictions are hard, especially when they are about future events. In the absence of useful information sent back from the future, memory-management subsystems are forced to rely on observations of recent behavior and an assumption that said behavior is likely to continue. The kernel's memory-management decisions are opaque to user space, though, and often result in less-than-optimal performance. A pair of patch sets from SeongJae Park tries to make memory-usage patterns visible to user space, and to let user space change memory-management decisions in response.

Security updates have been issued by Debian (netty and netty-3.9), Fedora (ceph, dovecot, poppler, and webkit2gtk3), openSUSE (inn and rmt-server), Oracle (openjpeg2), Red Hat (rabbitmq-server), Scientific Linux (openjpeg2), SUSE (dnsmasq, rsyslog, and slurm), and Ubuntu (php7.0).

The LWN.net Weekly Edition for February 20, 2020 is available.

Stable kernels 5.5.5, 5.4.21, and 4.19.105 have been released, with the usual set of important fixes.

At this point, most of the kernel work to avoid the year-2038 apocalypse has been completed. Said apocalypse could occur when time counted in seconds since 1970 overflows a 32-bit signed value (i.e. time_t). Work in the GNU C Library (glibc) and other C libraries is well underway as well. But the "fun" is just beginning for distributions, especially those that support 32-bit architectures, as a recent Debian discussion reveals. One of the questions is: how much effort should be made to support 32-bit architectures as they fade from use and 2038 draws nearer?

The Linux Foundation's Core Infrastructure Initiative and Harvard University's Lab for Innovation Science have teamed up on a census of the most critical open-source components in today's production applications. The report [PDF], titled "Vulnerabilities in the core", identified more than 200 projects and details 20 of them. More information can be found in the press release and, of course, the report. "This Census II analysis and report represent important steps towards understanding and addressing structural and security complexities in the modern day supply chain where open source is pervasive, but not always understood. Census II identifies the most commonly used free and open source software (FOSS) components in production applications and begins to examine them for potential vulnerabilities, which can inform actions to sustain the long-term security and health of FOSS. Census I (2015) identified which software packages in the Debian Linux distribution were the most critical to the kernel’s operation and security."

Security updates have been issued by CentOS (firefox, java-1.7.0-openjdk, ksh, and sudo), Debian (php7.0 and python-django), Fedora (cacti, cacti-spine, mbedtls, and thunderbird), openSUSE (chromium, re2), Oracle (firefox, java-1.7.0-openjdk, and sudo), Red Hat (openjpeg2 and sudo), Scientific Linux (java-1.7.0-openjdk and sudo), SUSE (dbus-1, dpdk, enigmail, fontforge, gcc9, ImageMagick, ipmitool, php72, sudo, and wicked), and Ubuntu (clamav, linux, linux-aws, linux-aws-hwe, linux-azure, linux-gcp, linux-gke-4.15, linux-hwe, linux-kvm, linux-oracle, linux-raspi2, linux-snapdragon, linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon, linux-aws-5.0, linux-azure, linux-gcp, linux-gke-5.0, linux-oracle-5.0, linux-azure, linux-kvm, linux-oracle, linux-raspi2, linux-raspi2-5.3, linux-lts-xenial, linux-aws, and qemu).

The idea behind kernel address-space layout randomization (KASLR) is to make it harder for attackers to find code and data of interest to use in their attacks by loading the kernel at a random location. But a single random offset is used for the placement of the kernel text, which presents a weakness: if the offset can be determined for anything within the kernel, the addresses of other parts of the kernel are readily calculable. A new "finer-grained" KASLR patch set seeks to remedy that weakness for the text section of the kernel by randomly reordering the functions within the kernel code at boot time.

A bit belatedly, Kees Cook looks at some security-relevant changes in Linux 5.4 in a blog post. He lists a small handful of changes, including: "After something on the order of 8 years, Linux can now draw a bright line between 'ring 0' (kernel memory) and 'uid 0' (highest privilege level in userspace). The 'kernel lockdown' feature, which has been an out-of-tree patch series in most Linux distros for almost as many years, attempts to enumerate all the intentional ways (i.e. interfaces not flaws) userspace might be able to read or modify kernel memory (or execute in kernel space), and disable them. While Matthew Garrett made the internal details fine-grained controllable, the basic lockdown LSM can be set to either disabled, 'integrity' (kernel memory can be read but not written), or 'confidentiality' (no kernel memory reads or writes). Beyond closing the many holes between userspace and the kernel, if new interfaces are added to the kernel that might violate kernel integrity or confidentiality, now there is a place to put the access control to make everyone happy and there doesn’t need to be a rehashing of the age old fight between 'but root has full kernel access' vs 'not in some system configurations'."

Security updates have been issued by Arch Linux (systemd and thunderbird), Debian (clamav, libgd2, php7.3, spamassassin, and webkit2gtk), Fedora (kernel, kernel-headers, and sway), Mageia (firefox, kernel-linus, mutt, python-pillow, sphinx, thunderbird, and webkit2), openSUSE (firefox, nextcloud, and thunderbird), Oracle (firefox and ksh), Red Hat (curl, java-1.7.0-openjdk, kernel, and ruby), Scientific Linux (firefox and ksh), SUSE (sudo and xen), and Ubuntu (clamav, php5, php7.0, php7.2, php7.3, postgresql-10, postgresql-11, and webkit2gtk).

The idea of an ID-shifting virtual filesystem that would remap user and group IDs before passing requests through to an underlying real filesystem has been around for a few years but has never made it into the mainline. Implementations have taken the form of shiftfs and shifting bind mounts. Now there is yet another approach to the problem under consideration; this one involves a theoretically simpler approach that makes almost no changes to the kernel's filesystem layer at all.

Security updates have been issued by Debian (evince, postgresql-9.4, and thunderbird), Fedora (ksh and libxml2), openSUSE (hostapd and nextcloud), Red Hat (chromium-browser, firefox, flash-plugin, and ksh), and SUSE (firefox and thunderbird).

The NetBSD 9.0 release is out. "This is the seventeenth major release of the NetBSD operating system and brings significant improvements in terms of hardware support, quality assurance, security, along with new features and hundreds of bug fixes." Significant new features include Arm64 support, better virtualization support, kernel address-space layout randomization, and more; see the release notes for details.

The 5.6-rc2 kernel prepatch is out for testing. Linus says: "More than half the rc2 patch is actually Documentation updates, because the kvm docs got turned into RST. Another notable chunk is just tooling updates, which is about 50/50 perf updates (much of it due to header file syncing) and - again - kvm".

OpenSSH 8.2 is out. This release removes support for the ssh-rsa key algorithm, which may disrupt connectivity to older servers; see the announcement for a way to check whether a given server can handle newer, more secure algorithms. Also new in this release is support for FIDO/U2F hardware tokens.