LWN.net

Stable kernels 5.5.6, 5.4.22, and 4.19.106 have been released. They all have alarge 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 tomaster. This call also has some interesting security implications: it canbe used to obtain a lot of information about the running system, and thecomplexity of the underlying implementation has made it more than usuallyprone to unpleasant bugs. In current kernels, the security controls aroundperf_event_open() are simple, though: if you have theCAP_SYS_ADMIN capability, perf_event_open() is availableto you (though the system administrator can make it available without anyprivilege at all). Somecurrent work to create a new capability for the perf events subsystem wouldseem to make sense, raising the question of why adding new capabilitiesisn'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: whichpages of memory will a given process need in the near future?Unfortunately, it turns out that predictions are hard, especially when theyare about future events. In the absence of useful information sent back fromthe future, memory-management subsystems are forced to rely on observationsof recent behavior and an assumption that said behavior is likelyto continue. The kernel's memory-management decisions areopaque to user space, though, and often result in less-than-optimalperformance. A pair of patch sets from SeongJae Park tries to make memory-usage patterns visible to user space, and to letuser 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 usualset of important fixes.

At this point, most of the kernel work to avoidthe 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 Clibraries is well underway as well. But the "fun" is just beginning for distributions,especially those that support 32-bit architectures, as a recent Debiandiscussion reveals. One of the questions is: how much effort should bemade to support 32-bit architectures as they fadefrom 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 layoutrandomization (KASLR) is to make it harder for attackers to find codeand dataof interest to use in their attacks by loading the kernel at a randomlocation. But a single random offset is used for the placement of thekernel text, which presents a weakness: if the offset can be determined foranything within the kernel, the addresses of other parts of the kernel are readilycalculable. A new "finer-grained" KASLR patch set seeks to remedy thatweakness for the text section of the kernel by randomly reordering thefunctions 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 andgroup IDs before passing requests through to an underlying real filesystemhas been around for a few years but has never made it into the mainline. Implementationshave taken the form of shiftfs and shifting bind mounts. Now there is yetanother approach to the problem under consideration; this one involvesa theoretically simpler approach that makesalmost 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 systemand brings significant improvements in terms of hardware support,quality assurance, security, along with new features and hundreds ofbug fixes." Significant new features include Arm64 support, bettervirtualization support, kernel address-space layout randomization, andmore; see the releasenotes for details.

The 5.6-rc2 kernel prepatch is out fortesting. Linus says: "More than half the rc2 patch is actuallyDocumentation updates, because the kvm docs got turned into RST.Another notable chunk is just tooling updates, which is about 50/50perf 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 keyalgorithm, which may disrupt connectivity to older servers; see theannouncement for a way to check whether a given server can handle newer,more secure algorithms. Also new in this release is support for FIDO/U2Fhardware tokens.

The5.5.4,5.4.20,4.19.104,4.14.171,4.9.214, and4.4.214stable kernels have all been released; each contains a relatively large setof important fixes.

Back in November 2019, Mike Rapoport madethe case that there is too much address-space sharing in Linuxsystems. This sharing can be convenient and good for performance, but inan era of advanced attacks and hardware vulnerabilities it also facilitatessecurity problems. At that time, he proposed a number of possible changesin general terms; he has now come back with a patchimplementing a couple of address-space isolation options for the memfd mechanism. This work demonstrates thesort of features we may be seeing, but some of the hard work has been leftfor the future.

Security updates have been issued by Debian (debian-security-support, postgresql-11, and postgresql-9.6), Fedora (cutter-re, firefox, php-horde-Horde-Data, radare2, and texlive-base), openSUSE (docker-runc), Oracle (kernel), Red Hat (sudo), and Ubuntu (firefox).

Stable-kernel updates are, unsurprisingly, supposed to be stable; that iswhy the first of the rulesfor stable-kernel patches requires them to be "obviously correctand tested". Even so, for nearly as long as the kernel community has been producing stable updatereleases, said community has also been complaining about regressions thatmake their way intothose releases. Back in 2016, LWN did someanalysis that showed the presence of regressions in stable releases, thoughat a rate that many saw as being low enough. Since then, the volume ofpatches showing up in stable releases has grown considerably, so perhapsthe time has come to see what the situation with regressions is with current stable kernels.

Security updates have been issued by Arch Linux (dovecot, firefox, ksh, and webkit2gtk), Debian (firefox-esr and openjdk-8), Mageia (exiv2, flash-player-plugin, python-waitress, and vim and neovim), openSUSE (pcp and rubygem-rack), Oracle (kernel), Red Hat (sudo), and Slackware (libarchive).

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

It seems unlikely that anyone on any "side" of the systemd war that hasraged in Debian over the last few years thought that the results of the recent general resolution (GR)vote ended the matter. The vote showed a clear preference for moving aheadwith systemd as the preferred init system, though it was far from any kindof landslide—there were definitely plenty of voters who would have preferred adifferent outcome. It was a complicatedGR, with a wide spectrum of options, but at this point, the project as a whole has spoken. Actually implementing some of the changes that theGR enabled may not have the smooth path that some might have hoped for, however.

On the Google Project Zero blog, Jann Horn looksat a number of vulnerabilities in a Samsung Android kernel, some ofwhich are caused by the addition of out-of-tree "security" features."The Samsung kernel on the A50 contains an extra security subsystem(named 'PROCA', short for 'Process Authenticator', with code insecurity/proca/) to track process identities. By combining several logicissues in this subsystem (which, on their own, can already cause a mismatchbetween the tracking state and the actual process state) with a brittlecode pattern, it is possible to cause memory unsafety by winning a racecondition."

Security updates have been issued by CentOS (spice-gtk), Debian (libemail-address-list-perl), openSUSE (chromium, libqt5-qtbase, nginx, systemd, and wicked), Oracle (spice-gtk), Slackware (firefox and thunderbird), and Ubuntu (libexif and Yubico PIV Tool).

Stable kernels 5.5.3, 5.4.19, and 4.19.103 have been released. They all containmany important fixes throughout the tree and users should upgrade.

From a high-level perspective, Lua and Python are similar languages; both are "scripting" languages that are compiled into bytecode instructions that run on avirtual machine. But the focus of Lua has generally been toward embeddingthe language into some larger application or system, rather than as an alternative for, say, Python, Perl, or Ruby as a general-purposelanguage. That is not to say that Lua is not capable of handling any ofthe tasks those other languages do, but that it has not really been thetarget, seemingly. Some recent discussions in the Lua community haveexplored possible changes in that regard, particularly around the idea ofproviding a larger, richer standard library.

Firefox 73.0 has been released. This version includes two features thathelp users view and read website content more easily; a new global defaultzoom level setting and a "readability backplate" solution to make websitesin High Contrast Mode more readable without disabling backgroundimages. See the releasenotes for details.

Security updates have been issued by Debian (checkstyle), Fedora (poppler), Oracle (kernel), Red Hat (389-ds:1.4, java-1.7.1-ibm, java-1.8.0-ibm, nss-softokn, and spice-gtk), and Scientific Linux (spice-gtk).

Daniel Aleksandersen showshow to sandbox a daemon process using a set of systemd features."These directives combined would have stopped the specific remotecode execution vulnerability that afflicted OpenSMTPD. However, the keytakeaway is that you should strive to sandbox long-running andinternet-exposed services. There’s no need for your webserver to be able toload a kernel module, your email server to change the hostname, or your DNSserver to launch wget and schedule reoccurring tasks with cron."

Linus Torvalds released the 5.6-rc1prepatch and closed the merge window on February 9; at that point, 10,780 non-mergechangesets had been pulled into the mainline repository for 5.6. That issubstantially less than recent development cycles (14,350 for 5.5, 14,619for 5.4), but is similar to what was going on at this time last year(10,843 for 5.0-rc1 in January 2019). About 6,000 of those changes werepulled since the first 5.6 merge-windowarticle was written; read on for what was included in those changes.

Version 9.1 of the GNU debugger is out. There are many improvements; seethe announcement and thechangelog for details.

Security updates have been issued by Debian (ipmitool, libexif, and ppp), Fedora (glib2, java-1.8.0-openjdk, java-11-openjdk, libasr, libuv, mingw-gdk-pixbuf, mingw-SDL2, nethack, nghttp2, nodejs, nodejs-mixin-deep, nodejs-set-value, nodejs-yarn, opensmtpd, python-feedgen, runc, samba, sox, and texlive-base), Mageia (chromium-browser-stable, mgetty, openslp, qtbase5, spamassassin, sudo, and xmlrpc), openSUSE (ceph and chromium), Oracle (grub2 and kernel), SUSE (docker-runc, LibreOffice, and wicked), and Ubuntu (libxml2 and qtbase-opensource-src).

Linus has released 5.6-rc1 and closed themerge window for this development cycle. "This was actually aslightly smaller merge window than usual, but I think that what happened issimply that the holiday season impacted new development. It impacted the5.5 rc series less than I had expected, but seems to instead have caused5.6 to have slightly less development than normal."

One of the more eyebrow-raising features to go into the 5.6 kernel is theability to load TCP congestion-control algorithms as BPF programs; networking developer Toke Høiland-Jørgensen described it as acontinuation of the kernel's "march towards becoming BPFruntime-powered microkernel". On itsface, congestion control is a significant new functionality to hand over toBPF, taking it farbeyond its existing capabilities. When one looks closer, though, one'seyebrow altitude may well increase further; the implementation of thisfeature breaks new ground in a couple of areas.

Over on the Ardour forum, Paul Davis wonders whether access to the source code is truly what users these days want or need. There are other closed-source digital audio workstations that are far more customizable than Ardour via a scripting language without needing any access to the source. "But perhaps for applications like Ardour, ones that do not yet exist, there ought to be a different development pathway. I remember once wondering if we should have implemented the entire GUI in PyGTK (i.e. Python). We didn't, and most of my curiosity was about whether it would have helped or hindered our development process. However, had we done so, one of the consequences would have been that many changes to the program would have been made simpler, easier to access and would require no 'rebuild'. I wonder if going forward, large-scale apps like Ardour ought to (as Reaper did relatively early in its life) consider the 'script extension system' to be a vital and critical part of the application infrastructure. This would mean, for example, writing large parts of 'core functionality' using this system, rather than dropping back into C++ to get things done. There are precedents for this: GNU Emacs, for example, is at some level written in C, but almost everything about the program is actually constructed in Emacs Lisp, its own 'scripting extension'. The C core of Emacs is so small and so irrelevant that it almost doesn't matter that it is there: if you want to modify or extend Emacs, you (almost always) write Lisp, not C."

Security updates have been issued by Arch Linux (chromium, python-django, and sudo), Debian (libexif and libxmlrpc3-java), Fedora (upx and xar), openSUSE (ucl and upx), Oracle (ipa), Scientific Linux (kernel), SUSE (e2fsprogs, libqt5-qtbase, nginx, pcp, php7, rubygem-rack, systemd, wicked, and xen), and Ubuntu (mariadb-10.1, mariadb-10.3, mesa, pillow, and python-reportlab).

On his blog, Peter Hutterer writes about some changes that will allow users to start deploying their own rules to modify keyboard layouts without driving themselves crazy.Many many moons ago before the Y2K bug was even in its larvae stage, the idea was that you could configure all of those because every UNIX tool had to be more flexible than your yoga teacher. I'm unsure to what extent this was actually ever the case but around 2007-ish the old keyboard driver got deprecated and the evdev driver made it's grand entrance. And one side-effect of that was that things broke. evdev uses different keycodes, so all those users that copy-pasted unnecessary XKB configuration into their xorg.conf now had broken keys because they were applying the wrong rules. After whacking enough moles that we got in trouble with the RSPCA [Royal Society for the Prevention of Cruelty to Animals] we started hardcoding the "evdev" ruleset everywhere. The xorg.conf option "XKBRules" became a noop and thus stopped breaking users' setups.Except that it also stopped users from deploying their own rules files - something that probably didn't really matter anyway. This had some unintended side-effects though. First, to have a working custom XKB layout you basically had to get it merged upstream. Yes, you could edit the files locally but they'd just be overwritten next time you update the packages. Second, getting rid of hardcoded things is hard so we're stuck with the evdev ruleset for the forseeable future. This was the situation until, well, now.

By many accounts, the kernel project uses outdated tooling, far behind thestate of the art that Kids Today tend to favor. The kernel's workflow hasworked well (enough) for years, but there are signs that it may not besustainable indefinitely. As a result, there has been an ongoing conversation aboutimproving the kernel's workflow, but little has changed so far. Thepostingof a simple tool called get-lore-mboxis a sign that the rate of change may be about to increase.

Security updates have been issued by CentOS (kernel-rt, qemu-kvm, spamassassin, and Xorg), Debian (ruby-rack-cors), Fedora (glibc), openSUSE (ImageMagick), Oracle (ipa, kernel, and qemu-kvm), SUSE (systemd), and Ubuntu (exiv2, mbedtls, and systemd).

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

Stable kernels 5.4.18, 4.19.102, and 4.14.170 have been released. They containimportant fixes and users should upgrade.

Browser tracking across different sites is certainly a major privacyconcern and one that is more acute when the boundaries between sites andbrowsers blur—or disappear altogether. That seems to be the underlyingtension in a "discussion" of an only tangentially related proposal beingmade by Google to the W3C TechnicalArchitecture Group (TAG). The proposal would change the handling ofthe User-Agent headers sent by browsers, but the discussion turnedto the unrelated X-Client-Data header that Chrome sends toGoogle-owned sites. The connection is that in both casessome feel that the web-search giant is misusing its position to the detriment ofits users and its competitors in the web ecosystem.

Support for the CoreOS Container Linux distribution is coming to an end on May 26;there will be no further updates after that date. Users are recommended tomove to Fedora CoreOS or someother distribution.

Stable kernels 5.5.2, 4.9.213, and 4.4.213 have been released with importantfixes. Users should upgrade.

Security updates have been issued by Debian (storebackup), openSUSE (e2fsprogs and wicked), Red Hat (containernetworking-plugins, ipa, kernel, kernel-rt, ksh, and qemu-kvm), Scientific Linux (ipa and qemu-kvm), SUSE (libqt5-qtbase, python-reportlab, and terraform), and Ubuntu (graphicsmagick, OpenSMTPD, spamassassin, and sudo).

Python 2 was officially "retired" on the last day of 2019, so no bugswill be fixed or changes made in that version of the language, at least by the coredevelopers—distributions and others will continue for some time tocome. But there are lots of Python projects that still supportPython 2.7 and may not be ready for an immediate clean break. Some changes thatwere made for the upcoming Python 3.9 release (which is currently scheduledfor October) are causing headaches because support for long-deprecated2.7-compatibility features is being dropped. That led to a discussion onthe python-dev mailing list about postponing thosechanges to give a bit more time to projects that want to dropPython 2.7 support soon, but not immediately.