Chaos Computer Club - archive feed

The Talos Linux distribution is built from scratch with the goal of providing a secure, verified, and minimal-footprint operating system for running Kubernetes clusters. Talos is designed to be immutable, minimal, and secure. Talos includes only the bare minimum required to run Kubernetes. This talk will cover how Talos uses Unified Kernel Images (UKIs) to provide immutable, verified, and secure booting. We will also cover how Talos partially conforms to the Linux Userspace API Group specification (UAPI) to implement some of the best practices with regards to fully verifiable TrustedBoot extending to the userspace. With the upcoming Talos 1.5 release, Talos ships with custom ISO and metal images that are UKI compliant. This means that the kernel, initramfs, and the root filesystem are all signed and verified by the bootloader. This allows Talos to provide a fully verified boot process from the bootloader to the userspace attested by TPM. This talk will cover the following topics: - Building UKI (ukify.py implementation in Go) - Issues with reproducibility - sd-boot - sd-stub - Upgrades/Rollbacks - systemd-measure and systemd-cryptenroll partial implementation in Go Future work: - IMA attestations for userspace runtime binaries (etcd, kubelet, containerd, etc) - Talos system extensions as sd-stub compatible sysexts - Kexec with Secureboot (how can we verify the TPM PCR values are populated correctly with values from new UKI) about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/Q9YBUZ/

The talk wants to provide a brief introduction into Confidential Containers Project. We'll discuss the rationale behind Confidential Computing and how concepts like Trusted Computing or Remote Attestation can be leveraged by end-users to guard their workloads not only from malicious actors but also their cloud service provider. Confidential Containers, an open-source CNCF project, aims to extend the experience of deploying cloud-native software on Kubernetes with the option to move sensitive workloads into confidential enclaves with minimal friction to the user experience. We'll introduce the components and container technologies we are using to achieve that, hint at some conceptual problems we are facing and provide a simple example of how confidential containers work in practice today. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GFDUHW/

The Linux Userspace team at Meta aims to make significant contributions to upstream userspace projects, while also ensuring that Meta is able to leverage those improvements. In this talk we'll give an overview of the team and brief history of how it was formalized. Then we'll dive deeper into some of the efforts we've worked on with the open source community and features we've adopted internally. Come if you enjoy hearing about systemd, BPF, distributions, and more! about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/YAHVZG/

Confidential compute is a new compute and programming paradigm to run an application in enclave, a run-time encrypted and authenticated trusted execution environment. We give an overview of the current technologies provided by AMD, Intel and ARM. We also give an overview of open source tools to leverage compute along a tutorial to enclave any applications with few command lines. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/7LVG99/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8P7XKH/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/AKNDS3/

All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/VAY88J/

The journey of developing a Linux platform to require very little in the way of configuration management, and how to virtually eliminate the need to modify code to change configuration. From configuration via scripts and evolving through a couple of configuration management products, we have used the idea of matching actions to timescales to transform how we do configuration management. We now do very little of it, and we have dramatically reduced its complexity. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/PVJQTH/

A quick overview of the work in progress to plumb PID FDs through Linux userspace, to achieve resilience and security improvements Process ID File Descriptors were introduced in Linux v5.3. They allow tracking a process reliably, without risking races and reuse attacks, as they always refer to one single process regardless of the actual PID, so if the process goes away the file descriptor will become invalid, even if a new process with the same PID reappears at the same time. Tracking processes in userspace is needed for various purposes, for example to authenticate actions via Polkit. This has been historically fragile, and various workarounds such as tracking a PID plus a UID plus a start time were put in place. D-Bus implementations also have methods to query a D-Bus' endpoint's PID, UID and GIDs. Recently work has been done to plumb PID FDs through all these components - systemd is able to receive queries asking for the session information or unit information via a PID FD, D-Bus implementations return the PID FD of a D-Bus endpoint via GetConnectionCredentials()/GetConnectionUnixProcessFD() (and they track processes via FD rather than PID), and Polkit allows writing rules authorizing by the systemd service name, which is possible to do safely thanks to using FDs all the way through. This lightning talk will quickly go through these improvements, showing how PID FDs can be used to improve userspace and provide concrete benefits. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/T3LJAM/

Image based OS updates are the future. One way to handle updates is via content-addressable synchronisation software, like casync and desync. This talk with give a presentation about the two - their overall design, feature set and strengths and weaknesses. It will also demonstrate a real world use-case of them. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/9MVYFU/

Some quick numbers and maybe curiousities from our work on evaluating which libraries need to be rebuilt for 64-bit time_t on armhf in Ubuntu using abi-compliance-checker. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/R3SWBQ/

The utmp implementation of glibc uses on quite some 64bit architectures a 32bit time variable, which leads to an overflow on 03:14:07 UTC on 19 January 2038. This talk will explain the current work on replacing utmp with logind. The year 2038 problem (also known as Y2038) is a time formatting bug on Unix systems with representing times after 03:14:07 UTC on 19 January 2038. This happens with a 32bit time_t, not with a 64bit time_t. The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But this isn't correct: on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries) glibc defines __WORDSIZE_TIME64_COMPAT32, which leads to the fact, that struct utmp (used for utmp, wtmp and btmp) and struct lastlog uses int32_t instead of time_t. So we have a Y2038 problem, which is not easy fixable, as this would require ABI and on disk format changes. In this talk I will speak about the background, which tools are affected and a radical solution: drop utmp, wtmp, btmp and lastlog completely and make use of systemd-logind and other tools instead. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/3Z7XEE/

A walkthrough of an interesting use case for the `FICLONE` ioctl: cloning file data into a tar archive, and cloning files out of it again. "Free" archiving and unarchiving at zero-copy speeds! Topics: - Copy-on-write and the `FICLONE` ioctl - The ancient `tar` format - A trick for adding arbitrary padding to the `tar` format in order to force file system page alignment - How to avoid symlink attacks and other TOCTOU issues, using the fairly recently introduced (linux 5.6) `openat2` system call. - An interesting bug in GNU tar At the end you'll receive a free autographed copy of [deduptar](https://git.sr.ht/~nullenenenen/deduptar/tree/master/item/README.md) to use for party tricks. 🥳 about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/99PZDY/

In light of the climate crises, and despite hardware getting faster and faster, fully powering down systems and back on on demand – the obvious choice – is still inconvenient, as boot times are still very long. Even ChromeOS still has not lowered its limit from ten seconds since years. Show the current status of the hobby project on x86 hardware, and give an overview of recent Linux kernel developments getting rid some of the delays. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HZY3K8/

A short case study on where we are with sandboxing APT; what gaps there are and what technologies we looked at. Downloading packages, verifying packages, installing packages, protecting user data from snoopy or broken maintainer scripts. A package manager has a lot of places that can need some sort of sandboxing. APT currently employs a minimal sandbox using a separate user for downloading, and optionally seccomp. This talk will explore that, the caveats and some more avenues like landlock, running apt in systemd isolation (useful for our apt-based .service units), file descriptor passing into sandbox. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8CGF9L/

Despite being ordinary computers with an ASIC for switching, in reality network hardware must still be treated differently from normal servers. In recent years a lot has improved, and vendors offer white box switches, allowing users to install a (network) operating system of their choice. Of course, the NOS needs to support the firmware interface for the particular ASIC, and this is not standardized: swtitchdev, DSA, SAI – none of them supporting all devices. Due to SONiC dominance, a lot of vendors seem to support SAI (Switch Abstraction Interface). But SAI requires a proprietary external Linux kernel module. On the NOS side, Open Network Linux was abandoned, and Azure’s SONiC is the new popular kid on the block, running a Docker daemon. There are other differences in the network hardware ecosystem: For example ONIE as the bootloader environment. Also working with upstream and using established software developing practices are lacking, resulting in a maintenance burden. Projects like DENT or OpenWrt go one step further by only supporting upstream Linux kernel interfaces, but now dentOS is also going to support SAI. This talk gives a short introduction into the network operating systems, and then focuses on DENT with the ONL fork dentOS, and shares experiences. Curiously, problems how to treat firmware blobs and discussions about what distribution to use as a base, are not unknown to these projects either. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/JVGVHG/

The TPM event log contains a history of all measurements made with the TPM. Complete with some context information for each measurement it is intended to help with recreating the current PCR contents. What was meant as a debugging tool turns out to be of vital importance when trying to remotely attest real life systems. This is mostly because of the overuse of certain PCR and the general mess that is x86 firmware. Sadly, there are many event logs. UEFI keeps one for its measurements and those done by EFI applications like GRUB and shim. If a system is booted in an MLE using tboot the ACM firmware code also maintains an event log that can be accessed via a pointer in an ACPI table. Now, systemd also has an event log that is mixed into the general journal log. Finally Linux IMA maintains it's own event log -- an append-only, in-kernel data structure. On top of that every bootloader or userspace application that wants to measure something into the TPM will also need to maintain an event log. How about we fix that? The talk will sketch out a solution that maintains a unified, global event log of the whole system on disk and exposes an interface for other applications that wish to measure things into the TPM. We'll also fix a race conditions in IMA as well as correctly handle S3 resume w.r.t measured boot while we're at it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HGMV9U/

Let's get you up to speed on Trusted Platform Modules (TPM 2.0) and Linux. Specifically, the various additions to basic Linux userspace, i.e. systemd in our goal to make measured boot a default on Linux. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HSEJY9/

This talk will discuss new features provided by the new kernel mount API interface about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/NYLYDK/

systemd v254 introduced a new reboot type: soft-reboot. It shortcuts the reboot process by not restarting the kernel, and instead shutting down userspace, followed by re-exec'ing systemd from the new rootfs, starting everything up again. Not only this allows to save time by virtue of doing less work, but it also allow select resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. In many environments where image-based Linux is used, service interruption intervals are key metrics that need to be minimized as much as possible. On a traditional package-based distributions, the rootfs can be updated piecemeal and userspace services can be restarted one by one - assuming a perfect running dependency tracking system and perfect reliability (need to restart D-Bus? Good luck!). On an image-based system this is obviously not possible, so a typical approach is relying on 'kexec', which loads a new kernel + initrd + rootfs, saving some time from a full reboot by avoiding giving back control to the firmware. But it turns out, it's not fast enough. systemd v254 introduced a new reboot type: soft-reboot. This follows in the kexec footsteps by shortcutting the reboot process, and brings it ever further: the kernel is not restarted at all, and instead userspace is shut down and then systemd is re-exec'ed from the new rootfs, starting up again. Not only this allows to save time by virtue of doing less work, but it also allow resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/XVV9QY/

Let's discuss about `bpfilter`, a userspace daemon that empowers services to create efficient packet-filtering BPF programs using a high-level representation of filtering rules. For a significant period, `bpfilter` wasn't more than an empty [usermode helper](https://cateee.net/lkddb/web-lkddb/STATIC_USERMODEHELPER.html) and an [abandoned patch series](https://lore.kernel.org/bpf/[email protected]). However, it has recently undergone active development as a userspace daemon, which can be found on GitHub at [https://github.com/facebook/bpfilter](https://github.com/facebook/bpfilter). This daemon now offers userspace services a swift and user-friendly interface to generate packet-filtering BPF programs dynamically. This discussion aims to provide further insights into `bpfilter`, including its current capabilities, performance, and ongoing development efforts. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/BKLNWP/

strace is a traditional userspace tracer utility for Linux, implemented using ptrace API. Despite of the abundance of various kernel tracing interfaces nowadays, there are certain classes of tasks that are still better served by strace. In this talk the maintainer of strace will provide examples of such tasks. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GUVYJ7/

Stopping the old and starting a new service afresh -- that is what service restart is roughly about. We will look what it comprises in more detail from service manager perspective and also from the service's client end. Thus we will look at how FDSTORE API can be used to smooth service restart. Furthermore, we will review how unit instances may provide further distinction between the stopped and the restarted service. Finally, we go through options that the existing service have to adopt these methods. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FYHCNJ/

With the introduction of "Forensic Container Checkpointing" in Kubernetes 1.25 it is possible to checkpoint containers. The ability to checkpoint containers opens up many new use cases. Containers can be migrated without loosing the state of the container, fast startup from existing checkpoints, using spot instances more effective. The primary use case, based on the title of the Kubernetes enhancement proposal, is the forensic analysis of the checkpointed containers. In this session I want to introduce the different possible use cases of "Forensic Container Checkpointing" with a focus on how to perform forensic analysis on the checkpointed containers. The presented use cases and especially the forensic analysis will be done as a live demo giving the audience a hands on experience. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FZNLRT/