Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

12:00 PM
Larry Loeb
Larry Loeb
Larry Loeb

Torvalds Gives In, Linux Kernel Gets Locked Down Early

After years of efforts and rewrites, Linus Torvalds has signed off on a new optional feature for Linux that locks down the kernel much earlier in the boot process than was previously the case.

It finally happened. After years of efforts and rewrites, Linus Torvalds has signed offon a new optional feature for Linux that locks down the kernel much earlier in the boot process than was previously being done. Matthew Garrett, David Howells and others bear the honor (aggravation?) for seeing this one through.

Torvalds has long been a critic of this kind of kernel hardening. But many distros of Linux made their own lockdown patches nevertheless, and he finally acquiesced.

"The majority of mainstream distributions have been carrying variants of this patchset for many years now, so there's value in providing a [patchset which] doesn't meet every distribution requirement, but gets us much closer to not requiring external patches," he noted in posting the code to GitHub.

The enclosed description of the new patchset is not sanguine. "This patchset introduces an optional kernel lockdown feature, intended to strengthen the boundary between UID 0 and the kernel." The document goes on to warn that, "When enabled, various pieces of kernel functionality are restricted. Applications that rely on low-level access to either hardware or the kernel may cease working as a result -- therefore this should not be enabled without appropriate evaluation beforehand." So, this may not be everyone's magic wand for security.

The wall between userland processes and the kernel is made higher with these patches. When enabled, the root user will not be able to affect the kernel the same way it currently can. This means that a compromised Linux root user account will then lose much of its luster to attackers. It won't be able to do those "special" things that attackers want to do.

The new module LSM (Linux Security Module) has two lockdown modes, which are called "integrity" and "confidentiality." Each restricts access to a different portion of the kernel's functionality.

If set to integrity, kernel features that allow userland to modify the running kernel are disabled. If set to confidentiality, kernel features that allow userland to extract confidential information from the kernel are also disabled.

This can be controlled via /sys/kernel/security/lockdown and overriden by kernel configuration. This allows the lockdown feature to be policy-driven, rather than encoding an implicit policy within the mechanism. One size (or feature) does not fit every situation.

The LSM was designed so that new or existing LSMs may implement finer-grained controls of the lockdown features. If you need to know the gory details of how this works, check out the lockdown_reason documentation which has been crammed into include/linux/security.h for the skinny about it.

Matthew Garret has also released some LSM information and code. It deals mostly with the "early loading" LSM implementations.

Garret's latest code adds support for early initialization of some LSMs, and then adds them to the list of names when full initialization is done later.

Early LSMs are initialized in link order and cannot be overridden via boot parameters, and cannot make use of kmalloc() (since the allocator isn't initialized yet).

The Linux kernel 5.4 branch should be the first to have the LSM show up.

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-11-28
In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is ...
PUBLISHED: 2020-11-27
blosc2.c in Blosc C-Blosc2 through 2.0.0.beta.5 has a heap-based buffer overflow when there is a lack of space to write compressed data.
PUBLISHED: 2020-11-27
npm package systeminformation before version 4.30.5 is vulnerable to Prototype Pollution leading to Command Injection. The issue was fixed with a rewrite of shell sanitations to avoid prototyper pollution problems. The issue is fixed in version 4.30.5. If you cannot upgrade, be sure to check or sani...
PUBLISHED: 2020-11-27
In Crafter CMS Crafter Studio 3.0.1 an unauthenticated attacker is able to inject malicious JavaScript code resulting in a stored/blind XSS in the admin panel.
PUBLISHED: 2020-11-27
In Crafter CMS Crafter Studio 3.0.1 an unauthenticated attacker is able to create a site with specially crafted XML that allows the retrieval of OS files out-of-band.