LWN on Security and Kernel (Paywall Has Ended)

The recently announced container-confinement breakout for containers started with runc is interesting from a few different perspectives. For one, it affects more than just runc-based containers as privileged LXC-based containers (and likely others) are also affected, though the LXC-based variety are harder to compromise than the runc ones. But it also, once again, shows that privileged containers are difficult—perhaps impossible—to create in a secure manner. Beyond that, it exploits some Linux kernel interfaces in novel ways and the fixes use a perhaps lesser-known system call that was added to Linux less than five years back.

The runc tool implements the container runtime specification of the Open Container Initiative (OCI), so it is used by a number of different containerization solutions and orchestration systems, including Docker, Podman, Kubernetes, CRI-O, and containerd. The flaw, which uses the /proc/self/exe pseudo-file to gain control of the host operating system (thus anything else, including other containers, running on the host), has been assigned CVE-2019-5736. It is a massive hole for containers that run with access to the host root user ID (i.e. UID 0), which, sadly, covers most of the containers being run today.

There are a number of sources of information on the flaw, starting with the announcement from runc maintainer Aleksa Sarai linked above. The discoverers, Adam Iwaniuk and Borys Popławski, put out a blog post about how they found the hole, including some false steps along the way. In addition, one of the LXC maintainers who worked with Sarai on the runc fix, Christian Brauner, described the problems with privileged containers and how CVE-2019-5736 applies to LXC containers. There is a proof of concept (PoC) attached to Sarai's announcement, along with another more detailed PoC he posted the following day after the discoverers' blog post.

It should come as no surprise that plugging untrusted devices into a computer system can lead to a wide variety of bad outcomes—though often enough it works just fine. We have reported on a number of these kinds of vulnerabilities (e.g. BadUSB in 2014) along the way. So it will not shock readers to find out that another vulnerability of this type has been discovered, though it may not sit well that, even after years of vulnerable plug-in buses, there are still no solid protections against these rogue devices. This most-recent entrant into this space targets the Thunderbolt interface; the vulnerabilities found have been dubbed "Thunderclap".

There are several different versions of Thunderbolt, either using Mini DisplayPort connectors (Thunderbolt 1 and 2) or USB Type-C (Thunderbolt 3). According to the long list of researchers behind Thunderclap, all of those are vulnerable to the problems they found. Beyond that, PCI Express (PCIe) peripherals are also able to exploit the Thunderclap vulnerabilities, though they are a bit less prone to hotplugging. Thunderclap is the subject of a paper [PDF] and web site. It is more than just a bunch of vulnerabilities, however, as there is a hardware and software research platform that they have developed and released. A high-level summary of the Thunderclap paper was posted to the Light Blue Touchpaper blog by Theo Markettos, one of the researchers, at the end of February.

Kernel developers are used to having to defend their work when posting it to the mailing lists, so when a longtime kernel developer describes their own work as "expensive and nasty", one tends to wonder what is going on. The patch set in question is core scheduling from Peter Zijlstra. It is intended to make simultaneous multithreading (SMT) usable on systems where cache-based side channels are a concern, but even its author is far from convinced that it should actually become part of the kernel.
SMT increases performance by turning one physical CPU into two virtual CPUs that share the hardware; while one is waiting for data from memory, the other can be executing. Sharing a processor this closely has led to security issues and concerns for years, and many security-conscious users disable SMT entirely. The disclosure of the L1 terminal fault vulnerability in 2018 did not improve the situation; for many, SMT simply isn't worth the risks it brings with it.

But performance matters too, so there is interest in finding ways to make SMT safe (or safer, at least) to use in environments with users who do not trust each other. The coscheduling patch set posted last September was one attempt to solve this problem, but it did not get far and has not been reposted. One obstacle to this patch set was almost certainly its complexity; it operated at every level of the scheduling domain hierarchy, and thus addressed more than just the SMT problem.

Zijlstra's patch set is focused on scheduling at the core level only, meaning that it is intended to address SMT concerns but not to control higher-level groups of physical processors as a unit. Conceptually, it is simple enough. On kernels where core scheduling is enabled, a core_cookie field is added to the task structure; it is an unsigned long value. These cookies are used to define the trust boundaries; two processes with the same cookie value trust each other and can be allowed to run simultaneously on the same core.

March 1, 2019 For much of its history, the kernel has had little in the way of formal testing infrastructure. It is not entirely an exaggeration to say that testing is what the kernel community kept users around for. Over the years, though, that situation has improved; internal features like kselftest and services like the 0day testing system have increased our test coverage considerably. The story is unlikely to end there, though; the next addition to the kernel's testing arsenal may be a unit-testing framework called KUnit.

The KUnit patches, currently in their fourth revision, have been developed by Brendan Higgins at Google. The intent is to enable the easy and rapid testing of kernel components in isolation — unit testing, in other words. That distinguishes KUnit from kernel's kselftest framework in a couple of significant ways. Kselftest is intended to verify that a given feature works in a running kernel; the tests run in user space and exercise the kernel that the system booted. They thus can be thought of as a sort of end-to-end test, ensuring that specific parts of the entire system are behaving as expected. These tests are important to have, but they do not necessarily test specific kernel subsystems in isolation from all of the others, and they require actually booting the kernel to be tested.

KUnit, instead, is designed to run more focused tests, and they run inside the kernel itself. To make this easy to do in any setting, the framework makes use of user-mode Linux (UML) to actually run the tests. That may come as a surprise to those who think of UML as a dusty relic from before the kernel had proper virtualization support (its home page is hosted on SourceForge and offers a bleeding-edge 2.6.24 kernel for download), but UML has been maintained over the years. It makes a good platform for something like KUnit without rebooting the host system or needing to set up virtualization.

Kernel code must often access data that is stored in user space. Most of the time, this access is uneventful, but it is not without its dangers and cannot be done without exercising due care. A couple of recent discussions have made it clear that this care is not always being taken, and that not all kernel developers fully understand how user-space access should be performed. The good news is that kernel developers are currently working on a set of changes to make user-space access safer in the future.

With the help of Natural Language Processing, an organisation can gain valuable insights, patterns, and solutions. Python is one of the widely used languages and it is implemented in almost all fields and domains. In this article, we list down 10 important Python Natural Language Processing Language libraries.

On June 27th, Red Hat will not only be hosting one of the best technical gatherings of 2019, but it will be doing so in Washington D.C. — not San Francisco, Seattle, or ... DevNation Federal conference will bring together industry experts and key maintainers of popular open source projects in a one-day immersive conference for federal developers.

The bug report count of KTextEditor (implementing the editing part used in Kate/KWrite/KDevelop/Kile/…) and Kate itself reached again some value over 200.
If you have time and need an itch to scratch, any help to tackle the currently open bugs would be highly appreciated.
The full list can be found with this bugs.kde.org query.
[...]
The team working on the code is small, therefore please be a bit patient if you wait for reactions. I hope we have improved our reaction time in the last months but we still are lacking in that respect.

In the last month, we’ve polished the user interface and added the last planned features to Blender 2.80. The details can be found in the weekly development notes.
Now we are freezing the user interface, so that there is a stable base for creating documentation and tutorials. Settings will stay in the same place and screenshots should remain valid for the final 2.80 release. A handful of menu entries may be added, or a tooltip might be improved, but nothing major that would break documentation.

In order to meet the July release target for Blender 2.80, there is now an API and user-interface freeze on this next feature update for this leading open-source, cross-platform 3D modeling software.
Blender 2.80 has now entered its UI and API freeze milestone for the 2.80 release. The Blender settings should also be maintained now moving forward for the Blender 2.80 release and its Python API compatibility, including for add-ons.

FreeBSD 11.3 Beta 1

24 May: The first BETA build for the FreeBSD 11.3 release cycle is now available. ISO images for the amd64, armv6, arm64, i386, powerpc, powerpc64, and sparc64 architectures are available on most of our FreeBSD mirror sites.

While FreeBSD 12 is the latest and greatest stable series since the end of last year, for those still on FreeBSD 11 there is the 11.3 update due out for release in July while this weekend the first beta was issued.
FreeBSD 11.3 offers up the latest security updates and other stable bug fixes over FreeBSD 11.2 that was released nearly one year ago. But for those craving all the latest features and functionality, FreeBSD 12 is in release form or there is also FreeBSD 13-CURRENT.

Latest News

Top 15 Best Windows Emulators for Linux Enthusiasts

Although it’s hard for us Linux fanatics to delve in the world of Windows, as it seems, we all need to embrace Windows in time to time for some specific tasks. Linux, despite all its rewards, is still not the household name among regular computer users and chances are that most of your non-technical friends use Windows as their primary system. So, if you want to share some standard software or play those latest games, Windows is still the way to go. However, it’s impossible for us Linux folks to shift on Windows permanently and overlook the flexibility Linux has been affording us over the years. Luckily, a comprehensive set of powerful Windows emulators for Linux exists to make our life more comfortable and allow us the benefits of both systems concurrently.

6 Open Source Android Alternative Operating Systems For Mobiles

In the wake of the ongoing US-Huawei-Google tussle, many Android enthusiasts are wondering about the different alternative phone operating systems that are out there. We have Apple’s iOS at our disposal, but the cost of owning an iPhone makes it an impossible choice for many.
This prompted me to create a list of other Android alternatives that are being developed or being used in mobile devices. The options that have been included in this list are open source, so any developer can grab the code and fork it to create something new for free. Huawei is itself creating its own operating system but I haven’t included it on this as the details are scarce.

Fedora 31 Planning To Upgrade To RPM 4.15 For Faster Builds, Other Improvements

RPM 4.15 is due out this year as the latest RPM4 update and Fedora 31 is planning to make prompt use of RPM 4.15 given its new/improved features.
RPM 4.15 is expected to provide faster build performance, a dynamic build dependency generator, experimental chroot operations for non-root users, improved ARM detection, and a whole lot of fixes.
More Fedora: Sirko Kemter: Khmer Translation Sprint 3