Linux 5.13 with intrusion protection and sandbox

Share your love

After seven release candidates, Linus Torvalds decided to release the Linux kernel 5.13. The week after rc7 was pretty quiet, which led him to no longer hold back Linux 5.13. With more than 17,000 commits including merges, it is one of the largest releases in the 5.x series. Over 2000 developers contributed to the release. Nevertheless, Torvalds reassured in his release note that, despite its size, there was nothing really “outstandingly unusual” about it. He suspects the size increase in the extra week of the rc8 from Linux 5.12, which delayed the merge window from 5.13. Between the lines this means that additional patches and merges have built up due to this extra week. These have now also been incorporated into Linux 5.13.

The result is impressive. Control Flow Integrity (CFI) is introduced from the Android kernel to protect against attacks. Landlock allows sandboxes to be created for applications and system services. With the possibility of using kernel functions from eBPF programs, however, there is also a potentially risky feature in the Linux kernel. The Extended Berkeley Packet Filter (eBPF), which was once started as a firewall technology, is now an interpreter for programs, analogous to a small virtual machine.

Linux 5.12 already introduced Link Time Optimization (LTO) for the Clang compiler. This laid the foundation for Control Flow Integrity (CFI). In Linux 5.13, the CFI, which originally came from the Android kernel, could thus be included in the mainline stream.

CFI is supposed to protect the kernel from diverting the program flow with indirect function calls and manipulated return addresses. What sounds bulky is a new piece of the puzzle for protecting against a less complicated attack vector.

Read Also   Instructions: Watch 4K films in HDR on the Raspi 4

If attackers want to bring a system under their control, they have to put malicious code in the system in some form and have it executed. In the past, protective mechanisms concentrated on separating storage areas based on tasks and restricting rights. The No-Execute-Feature (NX) made data storage segments in the kernel not executable. Later, Intel’s Supervisor Mode Execution Prevention (SMEP) and ARM’s Privileged Execute Never (PXN) also prevented the kernel from (accidentally) executing code in userspace. The latter only if it is in the highly privileged kernel mode. In this way, no code can be slipped from the userspace.

Despite all efforts, sore points remained: indirect function calls and manipulated return addresses. With the former, the function call is not made as a fixed address, but indirectly via a pointer to the address. The address of the function is therefore not permanently coded in kernel code segments that are protected against manipulation, but rather as a variable on the stack or heap. Stack and heap are data segments that can be changed according to their nature.

The system also stores the return address on the stack for each function call. This is independent of whether the call is made via a static address or indirectly via a function pointer. The program flow should finally return to the original position after the function call. This return address can also be modified in certain attack scenarios.

In order to detect manipulations, CFI checks the function address before the call and the return address before the return. CFI divides functions into classes based on their prototype (arguments and return type). CFI only allows indirect function calls if the calling and called functions belong to the same class. Otherwise the system acknowledges the class difference with a kernel panic.

Read Also   E-trucks are said to have proven themselves in the logistics test

To protect the return address, CFI relies on a secure stack (trusted stack). This is created in the form of a shadow copy of the call stack (shadow call stack). The ideal approach would be a system cast in hardware such as Intel’s Control-Flow Enforcement Technology (CET) or ARM’s Pointer Authentication. However, both are not yet widely available, which is why they are reproduced in software. A reserved register is used on the ARM that points to the shadow call stack.

When the function is called, the return address is saved on the normal stack. In addition, CFI puts the return address on the shadow stack. At the end of the function, but before the return jump, CFI compares the sighted address on the normal stack with the shadow copy. If they are identical, the function can jump back to the address. If there is a discrepancy, the termination takes place in the form of a kernel panic.

More about the implementation of CFI explains its author Kees “Case” Cook in a presentation. CFI is currently limited to ARM64 in Linux 5.13. The support for x86 architectures (32- and 64-bit) is still being worked on.

After more than five years of development holds Landlock Entry into the Linux kernel. The Linux Security Module (LSM) created by Mickaël Salaün enables sandboxes in user space. The feature was inspired by macOS XNU Sandbox, FreeBSD Capsicum and OpenBSD Pledge / Unveil.

Landlock originally relied on eBPF and the kernel function seccomp(). By seccomp() A process can irreversibly curtail its rights and then only execute limited system calls. Landlock initially used eBPF programs that hooked into the security hooks of the kernel. They regulated access to system calls from the sandbox. The eBPF rules associated individual programs with parts of the file system. seccomp() restricted access to the file system in a special mode.

Read Also   What does XD mean in WhatsApp, why is it used and since when has it been used?

Der System-Call seccomp() However, Landlock narrowed it down too much due to the rigidly prescribed rights restriction, as it did not allow only specific system calls to be blocked. The use of eBPF for access control also turned out to be too unwieldy. After all, Landlock is now relying on its own system calls. The seccomp()– Approach has been dropped. A separate mechanism is also used for access control, which replaces the eBPF originally used in Landlock. Instead of filtering the system calls, it restricts access directly to kernel objects, such as the file hierarchy.

Reads a bit confusing the commit message to Landlock. Although Landlock is no longer up inside seccomp() and eBPF is what Landlock developer Salaün sees in combination with seccomp() and eBPF additional strengths. The function seccomp() can also cut sandbox processes if this makes sense and is feasible in the application. Operations can also be flexibly flanked by eBPF. However, both of these do not have to be an internal part of Landlock.

According to Salaün, examples of using Landlock include applications with integrated sandboxing, such as web browsers, web services or SSH servers. System services can be limited to their tasks with Landlock. In the event of an exploit, the damage to the respective system service or its sandbox remains contained. Sandbox tools like Minijail, Firejail and nsjail as well as Flatpak could benefit from the Sandbox API.

Article Source

Share your love