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
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-10-22
BQE BillQuick Web Suite 2018 through 2021 before allows SQL injection for unauthenticated remote code execution, as exploited in the wild in October 2021 for ransomware installation. SQL injection can, for example, use the txtID (aka username) parameter. Successful exploitation can include ...
PUBLISHED: 2021-10-22
Draytek VigorAP 1000C contains a stored cross-site scripting (XSS) vulnerability in the RADIUS Setting - RADIUS Server Configuration module. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload in the username input field.
PUBLISHED: 2021-10-22
Aplioxio PDF ShapingUp contains a buffer overflow which allows attackers to cause a denial of service (DoS) via a crafted PDF file.
PUBLISHED: 2021-10-22
Portable Ltd Playable v9.18 was discovered to contain an arbitrary file upload vulnerability in the filename parameter of the upload module. This vulnerability allows attackers to execute arbitrary code via a crafted JPEG file.
PUBLISHED: 2021-10-22
Swift File Transfer Mobile v1.1.2 and below was discovered to contain a cross-site scripting (XSS) vulnerability via the 'path' parameter of the 'list' and 'download' exception-handling.