Inkscape 1.2 released
Version 1.2 of the
Inkscape drawing tool has been released. New features include multi-page
support, editable markers, the ability to flow text around shapes, and
more; see the
release notes for details.
Hírolvasó
Security updates for Tuesday
Security updates have been issued by Debian (cifs-utils, ffmpeg, libxml2, and vim), Fedora (rsyslog), Mageia (chromium-browser-stable), SUSE (chromium, containerd, docker, e2fsprogs, gzip, jackson-databind, jackson-dataformats-binary, jackson-annotations, jackson-bom, jackson-core, kernel, nodejs8, openldap2, pidgin, podofo, slurm, and tiff), and Ubuntu (clamav, containerd, libxml2, and openldap).
[$] Dynamically allocated pseudo-filesystems
It is perhaps unusual to have a kernel tracing developer leading a
filesystem session, Steven Rostedt said, at the beginning of such a session at the
2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). But he was doing
so to
try to find a good way to dynamically allocate kernel data structures
for some of the pseudo-filesystems, such as sysfs, debugfs, and tracefs,
in the kernel.
Avoiding static allocations would save memory, especially on systems
that are not actually using any of the files in those filesystems.
SFC v. Vizio remanded back to California state courts
Software Freedom Conservancy (SFC)
has announced
that it succeeded with its motion in US Federal Court to send the case back
to California, where it was originally filed. The suit was filed
in October 2021 by SFC, as an owner of Vizio televisions, to get
the company to comply with the GPL on some of the code in the TVs. Back in November, Vizio had
asked to move the
case to Federal Court, because the GPL is only a copyright license
(which is a dispute handled at the Federal level) and not a contract (that
could be adjudicated in state court). Friday's ruling disagreed with that premise:
The May 13 ruling by the Honorable Josephine L. Staton stated that the
claim from Software Freedom Conservancy succeeded in the "extra element
test" and was not preempted by copyright claims, and the court finds "that
the enforcement of 'an additional contractual promise separate and distinct
from any rights provided by the copyright laws' amounts to an 'extra
element,' and therefore, SFC's claims are not preempted."
"The ruling is a watershed moment in the history of copyleft licensing. This ruling shows that the GPL agreements function both as copyright licenses and as contractual agreements," says Karen M. Sandler, executive director of Software Freedom Conservancy. Sandler noted that many in the Free and Open Source Software (FOSS) legal community argue incorrectly that the GPL and other copyleft licenses only function as copyright licenses.
[$] The netfslib helper library
A new helper library for network filesystems, called netfslib, was the subject
of a filesystem session at the
2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). David Howells
developed
netfslib, which was merged for 5.13 a year ago, and led the session.
Some filesystems, like AFS and Ceph, are already using some of the services
that netfslib provides, while others are starting to look into it.
Security updates for Monday
Security updates have been issued by CentOS (gzip, java-1.8.0-openjdk, java-11-openjdk, and zlib), Debian (adminer, htmldoc, imagemagick, libgoogle-gson-java, lrzip, openjdk-8, openssl, and ruby-nokogiri), Fedora (ecdsautils, et, libxml2, podman, and supertux), Mageia (cairo, clamav, curl, fish, freetype2, golang-github-prometheus-client, python-django-registration, python-nbxmpp, python-waitress, and xmlrpc-c), Red Hat (pcs), SUSE (curl, kernel, pidgin, and webkit2gtk3), and Ubuntu (tiff).
Candlelit Console patch set to the framebuffer console
Crystal Kolipe writes in about her work on the framebuffer console, and provides an article on
… how to add a 'night mode' to the OpenBSD framebuffer console to give the text a yellow tint for more comfortable night time viewing, along with quite a few other cosmetic tweaks such as adding support for strikethrough text and double underlining. The article explains how to dynamically adjust the colour pallette, add a new sysctl value, and add a new escape sequence to the console emulation code in the kernel.
Matthew Garrett: Can we fix bearer tokens?
Last month I wrote about how bearer tokens are just awful, and a week later Github announced that someone had managed to exfiltrate bearer tokens from Heroku that gave them access to, well, a lot of Github repositories. This has inevitably resulted in a whole bunch of discussion about a number of things, but people seem to be largely ignoring the fundamental issue that maybe we just shouldn't have magical blobs that grant you access to basically everything even if you've copied them from a legitimate holder to Honest John's Totally Legitimate API Consumer.
To make it clearer what the problem is here, let's use an analogy. You have a safety deposit box. To gain access to it, you simply need to be able to open it with a key you were given. Anyone who turns up with the key can open the box and do whatever they want with the contents. Unfortunately, the key is extremely easy to copy - anyone who is able to get hold of your keyring for a moment is in a position to duplicate it, and then they have access to the box. Wouldn't it be better if something could be done to ensure that whoever showed up with a working key was someone who was actually authorised to have that key?
To achieve that we need some way to verify the identity of the person holding the key. In the physical world we have a range of ways to achieve this, from simply checking whether someone has a piece of ID that associates them with the safety deposit box all the way up to invasive biometric measurements that supposedly verify that they're definitely the same person. But computers don't have passports or fingerprints, so we need another way to identify them.
When you open a browser and try to connect to your bank, the bank's website provides a TLS certificate that lets your browser know that you're talking to your bank instead of someone pretending to be your bank. The spec allows this to be a bi-directional transaction - you can also prove your identity to the remote website. This is referred to as "mutual TLS", or mTLS, and a successful mTLS transaction ends up with both ends knowing who they're talking to, as long as they have a reason to trust the certificate they were presented with.
That's actually a pretty big constraint! We have a reasonable model for the server - it's something that's issued by a trusted third party and it's tied to the DNS name for the server in question. Clients don't tend to have stable DNS identity, and that makes the entire thing sort of awkward. But, thankfully, maybe we don't need to? We don't need the client to be able to prove its identity to arbitrary third party sites here - we just need the client to be able to prove it's a legitimate holder of whichever bearer token it's presenting to that site. And that's a much easier problem.
Here's the simple solution - clients generate a TLS cert. This can be self-signed, because all we want to do here is be able to verify whether the machine talking to us is the same one that had a token issued to it. The client contacts a service that's going to give it a bearer token. The service requests mTLS auth without being picky about the certificate that's presented. The service embeds a hash of that certificate in the token before handing it back to the client. Whenever the client presents that token to any other service, the service ensures that the mTLS cert the client presented matches the hash in the bearer token. Copy the token without copying the mTLS certificate and the token gets rejected. Hurrah hurrah hats for everyone.
Well except for the obvious problem that if you're in a position to exfiltrate the bearer tokens you can probably just steal the client certificates and keys as well, and now you can pretend to be the original client and this is not adding much additional security. Fortunately pretty much everything we care about has the ability to store the private half of an asymmetric key in hardware (TPMs on Linux and Windows systems, the Secure Enclave on Macs and iPhones, either a piece of magical hardware or Trustzone on Android) in a way that avoids anyone being able to just steal the key.
How do we know that the key is actually in hardware? Here's the fun bit - it doesn't matter. If you're issuing a bearer token to a system then you're already asserting that the system is trusted. If the system is lying to you about whether or not the key it's presenting is hardware-backed then you've already lost. If it lied and the system is later compromised then sure all your apes get stolen, but maybe don't run systems that lie and avoid that situation as a result?
Anyway. This is covered in RFC 8705 so why aren't we all doing this already? From the client side, the largest generic issue is that TPMs are astonishingly slow in comparison to doing a TLS handshake on the CPU. RSA signing operations on TPMs can take around half a second, which doesn't sound too bad, except your browser is probably establishing multiple TLS connections to subdomains on the site it's connecting to and performance is going to tank. Fixing this involves doing whatever's necessary to convince the browser to pipe everything over a single TLS connection, and that's just not really where the web is right at the moment. Using EC keys instead helps a lot (~0.1 seconds per signature on modern TPMs), but it's still going to be a bottleneck.
The other problem, of course, is that ecosystem support for hardware-backed certificates is just awful. Windows lets you stick them into the standard platform certificate store, but the docs for this are hidden in a random PDF in a Github repo. Macs require you to do some weird bridging between the Secure Enclave API and the keychain API. Linux? Well, the standard answer is to do PKCS#11, and I have literally never met anybody who likes PKCS#11 and I have spent a bunch of time in standards meetings with the sort of people you might expect to like PKCS#11 and even they don't like it. It turns out that loading a bunch of random C bullshit that has strong feelings about function pointers into your security critical process is not necessarily something that is going to improve your quality of life, so instead you should use something like this and just have enough C to bridge to a language that isn't secretly plotting to kill your pets the moment you turn your back.
And, uh, obviously none of this matters at all unless people actually support it. Github has no support at all for validating the identity of whoever holds a bearer token. Most issuers of bearer tokens have no support for embedding holder identity into the token. This is not good! As of last week, all three of the big cloud providers support virtualised TPMs in their VMs - we should be running CI on systems that can do that, and tying any issued tokens to the VMs that are supposed to be making use of them.
So sure this isn't trivial. But it's also not impossible, and making this stuff work would improve the security of, well, everything. We literally have the technology to prevent attacks like Github suffered. What do we have to do to get people to actually start working on implementing that?
comments
To make it clearer what the problem is here, let's use an analogy. You have a safety deposit box. To gain access to it, you simply need to be able to open it with a key you were given. Anyone who turns up with the key can open the box and do whatever they want with the contents. Unfortunately, the key is extremely easy to copy - anyone who is able to get hold of your keyring for a moment is in a position to duplicate it, and then they have access to the box. Wouldn't it be better if something could be done to ensure that whoever showed up with a working key was someone who was actually authorised to have that key?
To achieve that we need some way to verify the identity of the person holding the key. In the physical world we have a range of ways to achieve this, from simply checking whether someone has a piece of ID that associates them with the safety deposit box all the way up to invasive biometric measurements that supposedly verify that they're definitely the same person. But computers don't have passports or fingerprints, so we need another way to identify them.
When you open a browser and try to connect to your bank, the bank's website provides a TLS certificate that lets your browser know that you're talking to your bank instead of someone pretending to be your bank. The spec allows this to be a bi-directional transaction - you can also prove your identity to the remote website. This is referred to as "mutual TLS", or mTLS, and a successful mTLS transaction ends up with both ends knowing who they're talking to, as long as they have a reason to trust the certificate they were presented with.
That's actually a pretty big constraint! We have a reasonable model for the server - it's something that's issued by a trusted third party and it's tied to the DNS name for the server in question. Clients don't tend to have stable DNS identity, and that makes the entire thing sort of awkward. But, thankfully, maybe we don't need to? We don't need the client to be able to prove its identity to arbitrary third party sites here - we just need the client to be able to prove it's a legitimate holder of whichever bearer token it's presenting to that site. And that's a much easier problem.
Here's the simple solution - clients generate a TLS cert. This can be self-signed, because all we want to do here is be able to verify whether the machine talking to us is the same one that had a token issued to it. The client contacts a service that's going to give it a bearer token. The service requests mTLS auth without being picky about the certificate that's presented. The service embeds a hash of that certificate in the token before handing it back to the client. Whenever the client presents that token to any other service, the service ensures that the mTLS cert the client presented matches the hash in the bearer token. Copy the token without copying the mTLS certificate and the token gets rejected. Hurrah hurrah hats for everyone.
Well except for the obvious problem that if you're in a position to exfiltrate the bearer tokens you can probably just steal the client certificates and keys as well, and now you can pretend to be the original client and this is not adding much additional security. Fortunately pretty much everything we care about has the ability to store the private half of an asymmetric key in hardware (TPMs on Linux and Windows systems, the Secure Enclave on Macs and iPhones, either a piece of magical hardware or Trustzone on Android) in a way that avoids anyone being able to just steal the key.
How do we know that the key is actually in hardware? Here's the fun bit - it doesn't matter. If you're issuing a bearer token to a system then you're already asserting that the system is trusted. If the system is lying to you about whether or not the key it's presenting is hardware-backed then you've already lost. If it lied and the system is later compromised then sure all your apes get stolen, but maybe don't run systems that lie and avoid that situation as a result?
Anyway. This is covered in RFC 8705 so why aren't we all doing this already? From the client side, the largest generic issue is that TPMs are astonishingly slow in comparison to doing a TLS handshake on the CPU. RSA signing operations on TPMs can take around half a second, which doesn't sound too bad, except your browser is probably establishing multiple TLS connections to subdomains on the site it's connecting to and performance is going to tank. Fixing this involves doing whatever's necessary to convince the browser to pipe everything over a single TLS connection, and that's just not really where the web is right at the moment. Using EC keys instead helps a lot (~0.1 seconds per signature on modern TPMs), but it's still going to be a bottleneck.
The other problem, of course, is that ecosystem support for hardware-backed certificates is just awful. Windows lets you stick them into the standard platform certificate store, but the docs for this are hidden in a random PDF in a Github repo. Macs require you to do some weird bridging between the Secure Enclave API and the keychain API. Linux? Well, the standard answer is to do PKCS#11, and I have literally never met anybody who likes PKCS#11 and I have spent a bunch of time in standards meetings with the sort of people you might expect to like PKCS#11 and even they don't like it. It turns out that loading a bunch of random C bullshit that has strong feelings about function pointers into your security critical process is not necessarily something that is going to improve your quality of life, so instead you should use something like this and just have enough C to bridge to a language that isn't secretly plotting to kill your pets the moment you turn your back.
And, uh, obviously none of this matters at all unless people actually support it. Github has no support at all for validating the identity of whoever holds a bearer token. Most issuers of bearer tokens have no support for embedding holder identity into the token. This is not good! As of last week, all three of the big cloud providers support virtualised TPMs in their VMs - we should be running CI on systems that can do that, and tying any issued tokens to the VMs that are supposed to be making use of them.
So sure this isn't trivial. But it's also not impossible, and making this stuff work would improve the security of, well, everything. We literally have the technology to prevent attacks like Github suffered. What do we have to do to get people to actually start working on implementing that?
comments
Kernel prepatch 5.18-rc7
The 5.18-rc7 kernel prepatch has been
released for testing. Linus says: "So things continue to be fairly
calm, and as such this is likely the last rc before 5.18 unless something
bad happens next week".
Sunday's stable kernels
[$] Proactive reclaim for tiered memory and more
Memory reclaim in Linux is largely a reactive practice; the kernel tries to
find memory it can repurpose in response to the amount of free memory
falling too low. Developers have often wondered if a proactive reclaim
mechanism might lead to better performance, for some workloads at least,
and optimal use of tiered-memory systems will likely require more active
reclamation of memory as well. At the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM), Davidlohr Bueso
led a brief session on the topic.
[$] CXL 1: Management and tiering
Compute Express
Link (CXL) is an upcoming memory technology that is clearly on the
minds of Linux memory-management developers; there were five sessions
dedicated to the topic at the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). The first three
sessions, on May 3, covered various aspects of memory management in the
presence of CXL. It seems that
CXL may bring some welcome capabilities, especially for cloud-service
providers, but that will come at the cost of some headaches on the
kernel-development side.
Security updates for Friday
Security updates have been issued by Debian (chromium, postgresql-11, postgresql-13, and waitress), Fedora (curl, java-1.8.0-openjdk-aarch32, keylime, and pcre2), Oracle (gzip and zlib), Red Hat (subversion:1.10), SUSE (clamav, documentation-suse-openstack-cloud, kibana, openstack-keystone, openstack-monasca-notification, e2fsprogs, gzip, and kernel), and Ubuntu (libvorbis and rsyslog).
[$] Merging the multi-generational LRU
Many types of kernel changes can be hammered into shape on the mailing
lists. There are certain types of patches, however, that have a hard time getting to
the finish line that way; they are sufficiently large and invasive that
they need an actual gathering of the developers involved. The multi-generational LRU work (MGLRU) falls into this
category, which is why it was the subject of a full-hour session at the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). The discussion
held there may well have opened the doors for this code to be merged in the
near future.
AlmaLinux 8.6 released
Just one day after the RHEL 8.6 release, AlmaLinux 8.6 Stable has been released. See the release notes for more information.
The AlmaLinux OS Foundation is excited to announce that AlmaLinux OS 8.6 Stable is now available. Just like a flash after the beta release. This stable release is for the x86_64, aarch64 and ppc64le architectures and is ready for production installations and to power all your computing needs and workloads. Grab it from the nearest mirror and join us on the AlmaLinux Community Chat to discuss.
A big crop of new stable kernels
[$] Solutions for direct-map fragmentation
The kernel's "direct map" makes the entirety of a system's physical memory
available in the kernel's virtual address space. Normally, huge pages are used for
this mapping, making it relatively efficient to access. Increasingly,
though, there is a need to carve some pages out of the direct map; this
splits up those huge pages and makes the system as a whole less efficient.
During a memory-management session at the
2022
Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM),
Mike Rapoport led a session on direct-map fragmentation and how it might be
avoided.
Security updates for Thursday
Security updates have been issued by Fedora (microcode_ctl, mingw-SDL2_ttf, seamonkey, and thunderbird), Mageia (cifs-utils, gerbv, golang, libcaca, libxml2, openssl, python-pillow, python-rencode, python-twisted, python-ujson, slurm, and sqlite3), Red Hat (gzip, kernel, kpatch-patch, podman, rsync, subversion:1.10, and zlib), Scientific Linux (gzip), Slackware (curl), SUSE (clamav), and Ubuntu (curl, firefox, linux, linux-aws, linux-aws-5.13, linux-azure, linux-azure-5.13, linux-gcp, linux-gcp-5.13, linux-hwe-5.13, linux-kvm, linux-oracle, linux-raspi, linux, linux-aws, linux-aws-hwe, linux-azure, linux-azure-4.15, linux-dell300x, linux-gcp, linux-gcp-4.15, linux-hwe, linux-kvm, linux-oracle, linux-snapdragon, linux, linux-aws, linux-azure, linux-azure-5.4, linux-azure-fde, linux-gcp, linux-gcp-5.4, linux-gke, linux-gkeop, linux-gkeop-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux, linux-aws, linux-kvm, linux-lts-xenial, and linux-oem-5.14).
[$] LWN.net Weekly Edition for May 12, 2022
The LWN.net Weekly Edition for May 12, 2022 is available.
Red Hat Enterprise Linux 9 released
On May 10, Red Hat announced the release of Red Hat Enterprise Linux 9 (RHEL 9). Not surprisingly, the announcement is rather buzzword-heavy and full of marketing, though there are some technical details scattered in it. The release notes for the RHEL 9 beta are available, which have a lot more information. "The platform will be generally available in the coming weeks."
Building on decades of relentless innovation, the latest version of the world’s leading enterprise Linux platform is the first production release built from CentOS Stream, the continuously delivered Linux distribution that tracks just ahead of Red Hat Enterprise Linux. This approach helps the broader Red Hat Enterprise Linux ecosystem, from partners to customers to independent users, provide feedback, code and feature updates to the world’s leading enterprise Linux platform.