Security updates have been issued by Debian (libav), Fedora (kernel, libuv, and nodejs), Oracle (firefox), Red Hat (firefox and java-1.7.1-ibm), SUSE (clamav, cloud-init, dnsmasq, dpdk, ffmpeg, munge, opencv, and permissions), and Ubuntu (librabbitmq).
Security updates have been issued by Arch Linux (firefox), Fedora (cyrus-imapd, freeipa, haproxy, ImageMagick, python-pillow, rubygem-rmagick, sqlite, squid, and tnef), openSUSE (haproxy), Oracle (microcode_ctl), and Ubuntu (squid, squid3).
One of the features of the Clang/LLVM compiler that has been rather lacking
for GCC may finally be getting filled in. In a mid-November post
to the gcc-patches mailing list, David Malcolm described a new
static-analysis framework for GCC that he wrote. It could be the starting point for a
whole range of code analysis for the compiler.
Making a comparison between Linux and Kubernetes is often one of apples to
oranges. There are, however, some similarities and there is an effort
within the Kubernetes community to make Kubernetes more like a Linux
distribution. The idea was outlined in a session about Kubernetes
engineering at KubeCon
+ CloudNativeCon North America 2019. “You might have heard that
Kubernetes is the Linux of the cloud
and that’s like super easy to say, but what does it mean? Cloud is pretty
fuzzy on its own,” Tim Pepper, the Kubernetes release special interest group
co-chair said. He proceeded to provide some clarity on how the two
projects are similar.
On the Redox site, creator Jeremy Soller gives an update on the Unix-like operating system written in Rust. It is running on a System76 Galaga Pro laptop: “This particular hardware has full support for the keyboard, touchpad, storage, and ethernet, making it easy to use with Redox.” Meanwhile, he and the other Redox developers have been focusing on making it self-hosting: “Building Redox OS on Redox OS has always been one of the highest priorities of the project. Rustc seems to be only a few months of work away, after which I can begin to improve the system while running on it permanently, at least on one machine. With Redox OS being a microkernel, it is possible that even the driver level could be recompiled and respawned without downtime, making it incredibly fast to develop for. With this in place, I would work more efficiently on porting more software and tackling more hardware support issues, such as filling in the USB stack and adding graphics drivers.
But, more importantly than what I will be able to do, is the contributions by others that will be unlocked by having a fully self-hosted, microkernel Operating System written in Rust, Redox OS.”
Security updates have been issued by Debian (haproxy and libvorbis), Fedora (mod_auth_mellon and xen), Oracle (389-ds-base, kernel, and tcpdump), SUSE (bsdtar, java-11-openjdk, java-1_7_0-openjdk, and libxml2), and Ubuntu (nss and python-psutil).
was merged in Linux v2.6.24, its author, Rusty Russell, described
the goal as being for “common drivers to be efficiently used
across most virtual I/O
mechanisms“. Today, much progress has been made toward that goal, with virtio
supported by multiple hypervisors and guest drivers shipped by many operating
systems. But these applications of virtio are implemented in software, whereas
Michael Tsirkin’s “VirtIO
without the Virt” talk at KVM Forum 2019 laid out how
to implement virtio in hardware.
Security updates have been issued by Fedora (dpdk, mingw-djvulibre, mingw-hunspell, mingw-ilmbase, mingw-OpenEXR, php-symfony, php-symfony3, and rsyslog), openSUSE (chromium and squid), SUSE (aspell, cups, djvulibre, and dpdk), and Ubuntu (djvulibre).
Over on the Project Zero blog, Maddie Stone has a lengthy post about a zero-day exploit that was found and fixed in the Android Binder interprocess communication mechanism. The post details the search for the problem, which was apparently being used in the wild, its fix, and how it can be exploited. This is all part of an effort to “make zero-day hard“; one of the steps the project is taking is to disseminate more information on these bugs. “Complete detailed analysis of the 0-days from the point of view of bug hunters and exploit developers and share it back with the community. Transparency and collaboration are key. We want to share detailed root cause analysis to inform developers and defenders on how to prevent these types of bugs in the future and improve detection. We hope that by publishing details about the exploit and its methodology, this can inform threat intelligence and incident responders. Overall, we want to make information that’s often kept in silos accessible to all.”
Security updates have been issued by Fedora (oniguruma and thunderbird-enigmail), openSUSE (chromium, ghostscript, and slurm), Oracle (kernel), Red Hat (kpatch-patch), Slackware (bind), SUSE (python-ecdsa), and Ubuntu (bind9 and mariadb).
The idea of stacking (or chaining) Linux
security modules (LSMs) goes back
15 years (at least) at this point; progress
has definitely been made along
the way, especially in the last decade or so. It has been possible to
stack “minor” LSMs with one major LSM (e.g. SELinux, Smack, or AppArmor) for
some time, but mixing, say, SELinux and AppArmor in the same
system has not been possible. Combining major security solutions may not
seem like a truly important feature, but there is a use case where it is
pretty clearly needed: containers. Longtime LSM stacker (and Smack
maintainer) Casey Schaufler
gave a presentation at the 2019
Linux Security Summit Europe to report on the status and plans for
allowing arbitrary LSM stacking.
A key tenet in KVM is to reuse as much Linux infrastructure as possible
and focus specifically on processor virtualization. Back in 2007, this
meant a smaller code base and less friction with the other kernel
subsystems, especially when compared with other virtualization technologies
such as Xen. This led to KVM being merged into the mainline with relative
ease. A talk at this year’s KVM Forum looks at ways to better protect
guests, perhaps by moving away from that tenet.
The 13th KVM
Forum virtualization conference took place in Lyon, France in October
2019. One might think that development may have finished on the Kernel
Virtual Machine (KVM) module that was merged in Linux 2.6.20 in 2007, but
this year’s conference underscored the amount of work still being done,
particularly on side-channel attack mitigation, I/O device assignment with
VFIO and mdev, footprint reduction with micro virtual machines (VMs), and
with the ability to
run VMs nested within VMs. Many talks also involved the virtual machine
monitor (VMM) user-space programs that use the KVM kernel module—of which
QEMU is the most widely used.
Security updates have been issued by CentOS (kernel), Debian (ghostscript, mesa, and postgresql-common), Fedora (chromium, php-robrichards-xmlseclibs, php-robrichards-xmlseclibs3, samba, scap-security-guide, and wpa_supplicant), Mageia (cpio, fribidi, libapreq2, python-numpy, webkit2, and zeromq), openSUSE (ImageMagick, kernel, libtomcrypt, qemu, ucode-intel, and xen), Oracle (kernel), Red Hat (ghostscript, kernel, and kernel-rt), Scientific Linux (ghostscript and kernel), SUSE (bash, enigmail, ghostscript, ImageMagick, kernel, libjpeg-turbo, openconnect, and squid), and Ubuntu (ghostscript, imagemagick, and postgresql-common).
Security updates have been issued by Arch Linux (kernel, linux-lts, and linux-zen), CentOS (kernel, sudo, and thunderbird), Debian (linux-4.9), Fedora (samba), openSUSE (apache2-mod_auth_openidc, kernel, qemu, rsyslog, and ucode-intel), Oracle (kernel), Red Hat (kernel and kernel-rt), Scientific Linux (kernel), SUSE (kernel and microcode_ctl), and Ubuntu (kernel, libjpeg-turbo, linux, linux-hwe, linux-oem, linux, linux-hwe, linux-oem-osp1, and qemu).
Digging into the email that provides the cornerstone of Linux kernel
development is an endeavor that has become more popular over the last few
years. There are some practical reasons for analyzing the
kernel mailing lists and for correlating that information with the patches
that actually reach the mainline, including tracking the path that
patches take—or don’t take. Three researchers reported on some efforts
they have made on kernel email analysis at the 2019
Embedded Linux Conference Europe (ELCE), held in late October in Lyon, France.
This year saw the second edition of the Automated
Testing Summit (ATS) and the first that was open to all. Last year’s ATS
was an invitation-only
gathering of around 35 developers (that was described in an LWN article),
while this year’s event attracted
around 50 attendees; both were held in conjunction with the
Embedded Linux Conference Europe (ELCE), in Edinburgh, Scotland for 2018
and in Lyon, France this year. The basic problem has not changed—more
collaboration is needed between the different kernel testing systems—but
the starting points have been identified and work is progressing, albeit
slowly. Part of the problem, of course, is that all of these testing
efforts have their own constituencies and customers, who must be kept up
and running, even while any of this collaborative development is going on.