Security in Linux Kernel - Part 1

 

User-land security in Linux is pretty robust and finely ingrained into the design philosophy of the OS and inherited from the UNIX legacy. Beating at the centre of this robust OS is the equally robust heart of the OS - the Kernel.

Linux User has various tools and types of security at her disposal - such as enforcement of different roles and groups with varying levels of privileges, authorisations, access control using authentications, policy enforcement and logging, secure memory and process management techniques, secure protocols and of course, trust-worthy kernel. Roughly these techniques can also be described as DACs (Discretionary Access Controls) and MACs (Mandatory Access Controls). Example of DACs is the file and directory permissions in Linux (rwx for ugo) using which access to user data can be controlled.

What is the need?

But how does Linux Kernel ensures and enforces security in the Kernel-land? The Kernel relies on different MAC techniques like security modules, secure computing frameworks etc. Linux Security Modules (LSMs) were first included in the kernel version 2.5 back in 2001. Since then Linux kernel has seen many improvements and many varieties of LSMs. The latest Linux kernel offers a choice of at least 8 popular LSMs and many others which are under active development.

In User-land, different users and their processes are identified and careful isolation between them is achieved by checking and validating various access attributes, before granting or denying access to a resource (for example, a file or a shared memory segment). Similar access control is essential in kernel as well. To support various OS functionality, kernel uses different kernel objects like files, nodes, task structures, credentials, various IPC objects etc. It is of paramount importance to control access to such kernel objects. This is achieved using the LSMs.

What are options? 

There are different LSMs available to Linux users. The main LSMs available at present are

  • SELinux
  • AppArmor
  • SMACK
  • Yama
  • TOMOYO
  • LoadPin
  • SafeSetID
  • Lockdown

Apart from these, there are several others which are in development stage, though not accepted formally to the kernel. SELinux is the default out-of-box LSM used by RedHat and related Linux distributions, while Ubuntu and related distributions rely on AppArmor as default LSM. However, the end-user is free to select and configure any LSM as per the need.

To support LSMs, Linux Security Module Framework should be enabled in the Linux kernel. This is done by enabling CONFIG_SECURITY flag when building the kernel. As the kernel documentation explains, the LSM framework includes security fields in kernel data structures and calls to hook functions at critical points, which can be used to manage and perform access control in kernel. Additionally, LSM depend on Capabilities module, which forms a kind of foundation for them.

What types are available? 

Depending on their characteristics LSMs can be grouped as Major or Minor LSMs, or can be described as Stackable or Unstackable LSM. There is also a finer point of "exclusivity" of a module.

Certain types of LSMs can be stacked forming a chain of security. They work on a specific security aspect and pass the control to the next-in-chain module. Other types assume exclusive access to security enforcement. These modules distinguish themselves with LSM_FLAG_EXCLUSIVE flag, and hence cannot be loaded with other LSMs. Such modules can not be stacked to form chain of security.

Major LSMs

Major LSMs use configurable policies which get loaded from the user-space. These type of LSMs cannot be loaded at the same time and hence cannot be stacked, as they assume exclusive access to security objects. Major LSM can be configured while kernel is being compiled, or alternatively, they can be loaded by passing them as a command line argument to the kernel at the start time. SELinux, AppArmor and SMACK LSMs identify themselves as "exclusive" LSMs.

Minor LSMs

In contrast to Major LSMs, Minor LSMs have majority of their policies hard-coded in the module's code. Multiple Minor LSMs can be loaded at the same time to form a stack and when one modules finishes catering to a policy, next in line gets invoked, until all the modules in the stack get a chance to act. Since these modules do not rely on user-space configuration file, various options in the functionality of a module can be enabled or disabled using flags.

What are limitations?

While LSMs provide a powerful way of securing Linux kernel, there are certain limitations to LSMs.

As LSMs are geared more towards securing kernel objects, do not protect processes from attacks as they as positioned at much deeper level. LSMs reply on policy configuration file, but understanding and debugging policy specification language is not easy. This has led to a slower adaptation of LSMs in Linux installations. Competing LSMs complicate the scenario further.

References


Title image used from: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSNoKWDkJDrj5KLCWWlL3qX4NWajG8242HckA&usqp=CAU

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona
Read more

Common Git Tips

Image
Obtain list of commits git reflog --oneline git log --oneline These commands will also print commit ID - a.k.a. commit hash. Obtain list of branches created by a user git for-each-ref --format=' %(authorname) %09 %(refname)' --sort=authorname | grep <username> Obtain branch hash git show-ref branch_name Delete a local/remote branch Assume that a branch "bugfix/114355" is created to fix a bug. To delete the local branch: git branch -d bugfix/114355 git branch -D bugfix/114355 '-D' is same as specifying "--delete --force" . To remove the remote branch as well: git push origin --delete bugfix/114355 Undo last commit git reset --soft HEAD~1 Roll back repo to a commit To roll-back the repository to a particular commit, follow these steps. find the hash corresponding to the particular commit by checking the commit logs: git log --oneline roll back the repository by resetting the HEAD pointer: git reset --hard <commit_hash> Remove the latest co
Read more