Overview of Linux kernel security features

Address: https://www.linux.com/learn/docs/727873-overview-of-linux-kernel-security-features

 

Editor's Note: This is a guest post from James Morris, the Linux kernel security subsystem maintainer and manager of the mainline Linux kernel development team at oracle.

In this article, we'll take a high-level look at the security features of the Linux kernel. We'll start with a brief overview of traditional UNIX security, and
Rationale for extending that for Linux, then we'll discuss the Linux security extensions.

UNIX security-Discretionary Access Control

Linux was initially developed as a clone of the UNIX operating system in the early 1990 s. as such, it inherits the core UNIX security model-a form of Discretionary Access Control (DAC ). the security features of the Linux kernel have evolved significantly
To meet modern requirements, although unix dac remains as the core model.

Briefly, Unix DAC allows the owner of an object (such as a file) to set the security policy for that object-which is why it's called
DiscretionaryScheme. as a user, you can, for example, create a new file in your home directory and decide who else may read or write the file. this policy is implemented as permission bits attached to the file's inode, which may be set by the owner
Of the file. permissions for accessing the file, suchReadAnd
Write,May be set separately for the owner, a specific group, and other (I. e. Everyone else). This is a relatively simple form of access control lists (ACLs ).

Programs launched by a user run with all of the rights of that user, whether they need them or not. There is also
Superuser-An all-powerful entity which bypasses unix dac policy for the purpose of managing the system. Running a program as the superuser provides that program with all rights on the system.

Extending UNIX Security

Unix dac is a relatively simple security scheme, although, designed in 1969, it does not meet all of the needs of security in the Internet age. it does not adequately protect against buggy or misconfigured software, for example, which may be exploited
An attacker seeking unauthorized access to resources. privileged applications, those running as the superuser (by design or otherwise), are participant ly risky in this respect. once compromised, they can provide full system access to an attacker.

Functional requirements for security have also evolved over time. for example, many users require finer-grained policy than unix dac provides, and to control access to resources not covered by unix dac such as network packet flows.

It's worth noting that a critical design constraint for integrating new security features into the Linux kernel is that existing applications must not be broken. this is general constraint imposed by Linus for all new features. the option of Designing
A totally new security system from the ground up is not available-new features have to be joined fitted and compatible with the existing design of the system. in practical terms, this has meant that we end up with a collection of security enhancements rather
Than a monolithic security architecture.

We'll now take a look at the major Linux security extensions.

Extended DAC

Several of the first extensions to the Linux security model were to enhancements of existing unix dac features. the proprietary UNIX systems of the time had typically evolved their own security enhancements, often very similarly to each other, and there
Were some (failed) efforts to standardize these.

POSIX ACLs

POSIX access control lists for Linux are based on a draft POSIX standard. They extend the abbreviated unix dac ACLs to a much finer-grained scheme, allowing separate Permissions
For individual users and different groups. They're managed with the setfacl and getfacl commands. The ACLs are managed on disk via extended attributes, an extensible mechanic for storing metadata with files.

POSIX capabilities

POSIX capabilities are similarly based on a draft standard. The aim of this feature is to break up the power of the superuser, so that an application requiring
Some privilege does not get all privileges. the application runs with one or more coarse-grained privileges, such as cap_net_admin for managing network facilities. capabilities for programs may be managed with the setcap and getcap utilities. it's possible
To reduce the number of setuid applications on the system by assigning specific capabilities to them, however, some capabilities are very coarse-grained and inclutively provide a great deal of privilege.

Namespaces

Namespaces in Linux derive from the Plan 9 Operating System (the successor research project to Unix). It's a lightweight form of partitioning resources as seen by processes, so that they may,
For example, have their own view of filesystem mounts or even the process table. this is not primarily a security feature, but is useful for implementing security. one example is where each process can be launched with its own, private/tmp directory, invisible
To other processes, and which works seamlessly with existing application code, to eliminate an entire class of security threats.

The potential security applications are diverse. Linux namespaces have been used to help implement multi-level security, where files are labeled with security classifications, and potentially entirely hidden from users without an appropriate security clearance.

On login systems, namespaces are configured via Pluggable Authentication Modules (PAM) -- see the pam_namespace (8) man page.

Network Security

Linux has a very comprehensive and capable networking stack, supporting extends protocols and features. linux can be used both as an endpoint node on a network, and also as a router, passing traffic between interfaces according to networking policies.

Netfilter is an IP network layer framework which hooks packets which pass into, through and from the system. kernel-level modules may hook into this framework to examine packets and make security decisions
About them.
Iptables is one such module, which implements an IPv4 firewalling scheme, managed via the userland iptables tool. access control rules for IPv4 packets are installed into the kernel, and each packet must pass these rules to proceed through the networking
Stack. Also implemented in this codebase is stateful packet inspection and network access translation (NAT). firewalling is similarly implemented for IPv6.

Ebtables provides filtering at the link layer, and is used to implement access control for Linux bridges, while
Arptables provides filtering of ARP packets.

The networking stack also has des an implementation
IPSec, which provides confidentiality, authenticity, and integrity protection of IP networking. It can be used to implement VPNs, and also point to point security.

Cryptography

A cryptographic API is provided for use by kernel subsystems. it provides support for a wide range of cryptographic algorithms and operating modes, including commonly deployed ciphers, hash functions, and limited support for asypolicric cryptography. there
Are synchronous and asynchronous interfaces, the latter being useful for supporting cryptographic hardware, which offloads processing from General CPUs.

Support for hardware-based cryptographic features is growing, and several algorithms have optimized configurer implementations on common ubuntures. A key management subsystem is provided for managing cryptographic keys within the kernel.

Kernel users of the cryptographic API include the IPsec code, disk encryption schemes including
Ecryptfs and
DM-crypt, and kernel module signature verification.

Linux Security Modules

The Linux security modules (LSM) API implements hooks at all security-critical points within the kernel. A user of the Framework (an "LSM") can register with the API and receive callbacks from these hooks. all security-relevant information is safely passed
To the LSM, avoiding race conditions, and the LSM may deny the operation. This is similar to the netfilter hook-based API, although applied to the general kernel.

The lsm api allows different security models to be plugged into the kernel-typically access control frameworks. to ensure compatibility with existing applications, the LSM hooks are placed so that the Unix DAC checks are completed MED first, and only if they
Succeed, is LSM code invoked.

The following LSMS have been in0000ated into the mainline Linux kernel:

SELinux

Security Enhanced Linux (SELinux) is an implementation of fine-grained Mandatory Access Control (MAC) designed to meet a wide range of security requirements, from general purpose
Use, through to government and military systems which manage classified information. mac security differs from DAC in that the security policy is administered centrally, and users do not administer policy for their own resources. this helps contain attacks
Which exploit userland software bugs and misconfiguration.

In SELinux, all objects on the system, such as files and processes, are assigned security labels. all security-relevant interactions between entities on the system are hooked by LSM and passed to the SELinux module, which consults its security policy
Determine whether the operation shoshould continue. the SELinux security policy is loaded from userland, and may be modified to meet a range of different security goals. specified previous Mac schemes had fixed policies, which limited their application to General
Purpose computing.

SELinux is implemented as a standard feature in fedora-based distributions, and widely deployed.

Smack

The smack LSM was designed to provide a simple form of MAC security, in response to the relative complexity of SELinux. It's also implemented as a label-based scheme with a customizable policy. Smack
Is part of the tizen security architecture and has seen adoption generally in the embedded space.

Apparmor

Apparmor is a MAC scheme for confining applications, and was designed to be simple to manage. Policy is configured as application profiles using familiar Unix-style classes actions such as pathnames.
It is fundamentally different to SELinux and smack in that instead of direct labeling of objects, security policy is applied to pathnames. apparmor also features a learning mode, where the security behavior of an application is observed and converted automatically
Into a security profile.

Apparmor is shipped with Ubuntu and opensuse, and is also widely deployed.

Tomoyo

The
Tomoyo module is another MAC scheme which implements path-based security rather than object labeling. it's also aimed at simplicity, by utilizing a Learning Mode similar to apparmor's where the behavior of the system is observed for the purpose of generating
Security Policy.

What's different about tomoyo is that what's recorded are trees of process invocation, described as "domains ". for example, when the system boots, from init, as series of tasks are invoked which lead to a logged in user running a shell, and ultimately executing
A command, say ping. This particle chain of tasks is recorded as a valid domain for the execution of that application, and other invocations which have not been recorded are denied.

Tomoyo is intended for end users rather than system administrators, although it has not yet seen any appreciable adoption.

Yama

The Yama LSM is not an access control scheme like those described above. It's where miscellaneous DAC security enhancements are collected, typically from external projects such
Grsecurity.

Currently, enhanced restrictions on ptrace are implemented in Yama, and the module may be stacked with other LSMS in a similar manner to the capabilities module.

Audit

The Linux kernel features a comprehensive
Audit Subsystem, which was designed to meet government certification requirements, but also actually turns out to be useful. LSMS and other security components utilize the kernel audit API. the userland components are extensible and highly retriable.

Audit logs are useful for analyzing system behavior, and may help detect attempts at compromising the system.

Seccomp

Secure Computing Mode (seccomp) is a mechanic which restricts access to system cballs by processes. the idea is to reduce the attack surface of the kernel by preventing applications from entering system callthey don't need. the system call API is a wide
Gateway to the kernel, and as with all code, there have and are likely to be bugs present somewhere. given the privileged nature of the kernel, bugs in system cballs are potential avenues of attack. if an application only needs to use a limited number
System call, then restricting it to only being able to invoke those callces CES the overall risk of a successful attack.

The original seccomp Code, also known as "Mode 1", provided access to only four system CALS: read, write, exit, and sigreturn. these are the minimum required for a useful application, and this was intended to be used to run Untrusted code on otherwise
Idle systems.

A
Recent update to the Code allows for arbitrary specification of which system CILS are permitted for a process, and integration with audit logging. this "Mode 2" seccomp was developed for use as part of the Google Chrome OS.

Integrity Management

The kernel's integrity management subsystem may be used to maintain the integrity of files on the system. The integrity Measurement Architecture (IMA) component performs runtime integrity measurements
Of files using cryptographic hashes, comparing them with a list of valid hashes. The list itself may be verified via an aggregate hash stored in
TPM. Measurements stored med by Ima may be logged via the audit subsystem, and also used for remote attestation, where an external system verifies their correctness.

Ima may also be used for local integrity enforcement via the appraisal extension. valid measured hashes of files are stored as extended attributes with the files, and subsequently checked on access. these extended attributes (as well as other security-related
Extended attributes), are protected against offline attack by the extended verification module
(EVM) component, ideally in conjunction with the TPM. if a file has been modified, Ima may be configured via policy to deny access to the file. the digital signature extension allows IMA to verify the authenticity of files in addition to integrity
By checking RSA-Signed measurement hashes.

A simpler approach to integrity management is
DM-Verity module. this is a device mapper target which manages file integrity at the block level. it's intended to be used as part of a verified boot process, where an appropriately authorized caller brings a device online, say, a trusted partition containing
Kernel modules to be loaded later. The integrity of those modules will be transparently verified block by block as they are read from disk.

Hardening and platform security

Hardening techniques have been applied at varous levels, including in the build chain and in software, to help reduce the risk of system compromise.

Address Space Layout randomization (aslr) places various memory areas of a userland executable in random locations, which helps prevent certain classes of attacks.
This was adapted from the external Pax/grsecurity projects, along with several other software-based hardening features.

The Linux kernel also supports hardware security features where available, such
NX,
VT-D,
TPM,
TXT, and SMAP, along with cryptographic processing as previusly mentioned.

Summary

We 've covered, at a very high-level, how Linux kernel security has evolved from its UNIX roots, adapting to ever-changing security requirements. these requirements have been driven both by external changes, such as the continued growth of the Internet and
The increasing value of information stored online, as well as the increasing scope of the Linux user base.

Ensuring that the security features of the Linux kernel continue to meet such a wide variety of requirements in a changing landscape is an ongoing and challenging process.

James Morris is the Linux kernel security subsystem maintainer. he is the author of svirt (virtualization Security), multi-category security, the kernel cryptographic API, and has contributed to the SELinux, netfilter and IPSec projects. he works
Oracle as manager of the mainline Linux kernel development team, from his base in sysydney, Australia. follow James on
Https://blogs.oracle.com/linuxkernel.