Two Google plans that could make open source code more secure

Recently Google announced that it will fund the further development of Rust. Rust is a low-level programming language that is designed to be more memory secure than other popular programming languages, such as C.

Google has also proposed an end-to-end framework for supply chain integrity which it has dubbed Supply chain Levels for Software Artifacts (SLSA).

Rust in Linux

Google’s investment in Rust will take the form of a contract for Miguel Ojeda, who’s worked on programming language security, to write software in Rust for the Linux kernel. Adding Rust modules to the Linux kernel could improve security for phones, computers and servers, because the Linux kernel is used in all the different Linux distributions, and it is also the core kernel for Android, ChromeOS, and many embedded systems. Android already supports the Rust programming language for developing the OS itself.

Rust is already is a favorite language among programmers and the Rust for Linux community has already started adding support for the language to the Linux kernel build system. Traditionally, kernel programming was largely done in C, which has been around since 1972 and is more prone to some classes of security errors than contemporary programming languages.

The goal of the project is not to replace all the existing Linux code but rather to improve selective and new parts. Josh Aas, who runs ISRG‘s Prossimo project, plans to focus on certain security-critical components and drivers. The Prossimo Project is what Ojeda has been working on.

Memory secure

The density of memory safety bugs in the Linux kernel is already quite low due to high code quality, high standards of code review, and carefully implemented safeguards. However, memory safety bugs do still occur on a regular bases. On Android, vulnerabilities in the kernel are generally considered high-severity because they can result in a security model bypass due to the privileged mode that the kernel runs in.

Secure coding is something that every programmer wants to do, but what really makes the difference is making it easy to accomplish. And that is what Rust has the potential to do.

SLSA

The goal of SLSA (“Salsa”) is to improve code integrity, particularly open source code, making it more resilient to supply chain attacks. It is inspired by Google’s internal “Binary Authorization for Borg” process which has been in use for the past 8+ years and is mandatory for all of Google’s production workloads.

The SLSA framework will be designed to safeguard source integrity and build integrity. It should provide end-users with the ability to check the provenance of any code they’re installing, so they can tell if it has been tampered with.

SLSA consists of four levels, with SLSA 4 representing the ideal end state. The SLSA level will tell the end-user whether the source, build, provenance, and security aspects meet a certain standard.

Bringing secure code to the end user

Starting with a secure low level programming language and safeguarding that security until it reaches the end user sounds like a very good plan. But it will certainly not be achieved in a short span of time. Google sees adding a second, more memory secure, programming language to the Linux kernel as an opportunity to adopt best practices in terms of documentation and uniformity right away. The contract with Miguel Ojeda has the duration of one year, which certainly will be aimed at tackling the most elementary obstacles on the road to a secure kernel. If they reach the level where it is easier to add Rust elements to the kernel than it is to keep going in C, they will have made an important step.

Since many servers hosting software on the internet are running on Linux, improving the security of the OS of those servers can be a first step in the road to more secure and easy to verify software.

But getting the industry to accept a standard that provides the end-user with some sort of option to compare the security level of software will be an even bigger struggle. Unless some sort of legislation is introduced to enforce and monitor such a standard. But as we have seen in the past with bills trying to regulate the safety of IoT devices, getting governments to agree on the requirements they want vendors to meet, let alone to adapt an entire framework could prove to be a gargantuan task.

It will likely be left to developers who want to do the right thing to adopt the standard. Although many likely will, history suggests we generally get whatever level of security the path of least resistance leads to. That’s why making it easy for kernel developers to use Rust is so important, after all.

The post Two Google plans that could make open source code more secure appeared first on Malwarebytes Labs.