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

10/1/2019
12:00 PM
Larry Loeb
Larry Loeb
Larry Loeb
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Cloud Security Threats for 2021
Or Azarzar, CTO & Co-Founder of Lightspin,  12/3/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
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
Assessing Cybersecurity Risk in Todays Enterprises
Assessing Cybersecurity Risk in Todays Enterprises
COVID-19 has created a new IT paradigm in the enterprise and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27772
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in coders/bmp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned int`. This would most likely lead to an impact to application availability, but could po...
CVE-2020-27773
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/gem-private.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned char` or division by zero. This would most likely lead to an impact to appli...
CVE-2020-28950
PUBLISHED: 2020-12-04
The installer of Kaspersky Anti-Ransomware Tool (KART) prior to KART 4.0 Patch C was vulnerable to a DLL hijacking attack that allowed an attacker to elevate privileges during installation process.
CVE-2020-27774
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/statistic.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of a too large shift for 64-bit type `ssize_t`. This would most likely lead to an impact to application availability, but co...
CVE-2020-27775
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/quantum.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned char. This would most likely lead to an impact to application availability, but c...