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
- Linux Security Modules
- Linux Security Modules: General Security Hooks for Linux
- Linux Security Module Usage
Title image used from: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSNoKWDkJDrj5KLCWWlL3qX4NWajG8242HckA&usqp=CAU
Comments
Post a Comment