Linux Kernel Security - Inside the Linux Security Modules (LSMs)
The Linux Security Module (LSM) framework provides a mechanism for various security checks to be hooked by new kernel extensions.
The primary users of the LSM interface are Mandatory Access Control (MAC) extensions which provide a comprehensive security policy. Examples include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger MAC extensions, other extensions can be built using the LSM to provide specific changes to system operation when these tweaks are not available in the core functionality of Linux itself.
The topic deep dives into the
- Understanding LSMs,
- Types of LSMs,
- Architecture of LSM,
- The various hooks and the functionality provided by these hooks
What is the primary role of the Linux Security Module (LSM) framework as described in the talk?
Yes, The LSMs can be stacked. The restriction is that there is one Major LSM and than the minor LSMs can be stacked on top of it.
Thank you Vandana . It was quiet interesting and came to know about LSM idea and basic framework at Kernel End. It was nice Session .
Thanks Sairam!!
Does the order of LSMs matter?
The POSIX capability security functionality is been moved into the "capability" module which is the builtin extended security and these security checks should happen before any MAC implementations enforced by LSMs therefore the order of LSM seems to be reasonable.
You mention that using whitelisting (Mandatory Access Control) is an effective way of providing defense in depth by Access Control. Does anyone happen to know of any studies that compares the effectiveness of MAC to just relying on sandboxing and DAC?
The is the paper mentioned by NSA but the links are missing "Seminal 1998 NSA paper: The Inevitability of Failure describes additional security requirements"
We develop real time embedded systems and some IoT products, in which resources are already limited. It is hard to tell what impact there might be on a running system, when LSMs are activated. Before delving into these various LSMs, how can we find out if they interfere with normal operations, due to delays introduced by these calls? For example if we want to make a whitelist of allowed processes. what would you suggest we use, to have the least impact on performance?
Thank you Vandana for a great talk. I've heard about SELinux and AppArmor and I've seen the LSM hooks when browsing the kernel source code, but I have never read up on the the Why's and What's. This was a great introduction. Some questions:
- The LSM subsystems hooks adds some overhead. Is that overhead measurable or just in the noise?
- The hooks and ptrs also adds some complexity. Has there been vulnerabilities caused by these code paths?
Let me get back to you on these overhead data. Thanks!!
As I understand it, both AppArmor and SMACK were created to be somewhat simpler to administrate than SELinux. You mentioned that SMACK is used by Automotive Grade Linux.
- Do the majority of embedded Linux deployments use SMACK or is the usage pattern more evenly distributed?
- Does there exist some guidelines for choosing which LSM module to deploy for embedded Linux?
Q:Do the majority of embedded Linux deployments use SMACK or is the usage pattern more evenly distributed?
Ans: I don't have concrete data but I believe the usage pattern is more evenly distributed. Android uses SELinux.
Q: Does there exist some guidelines for choosing which LSM module to deploy for embedded Linux?
Ans: There is no guideline documented but it seems to dependent on the usage pattern. Another aspect is based features provided by the Major LSM implementation, Here's the link I found which shows the comparison among the Major LSMs on Tomoyo site which can be used as guide line to choose the LSM: http://tomoyo.osdn.jp/wiki-e/?WhatIs#comparison
When and how (or at least why) did the LSM Framework originate?
The initial implementation of SELinux came from National security agency(NSA) for fine-grained Mandatory access control implementation which was initially not accepted as another security feature inside the kernel and then eventually with the acceptance to add the framework that provide set of hooks to control operations on kernel objects and security opaque data pointers to hold security attributes and this would eventually be used to implement any desired model of security without affecting the whole system. The first set of patches was merged in as part of 2.6 release. Due to time restrictions, I have to cut down half of the slides. Hope i address your query. Thanks!!
The "security blobs", was that the void pointers associated with some kernel objects like superblock, task_struct, sk_buff?
I think you said that they were there to allow for more complex matching cases. Do you have an example of such matching? Is the audit logging one of those cases? I assume that it needs some state to know how many times a certain object has been accessed?
I've heard of seccomp as a way to filter system calls. Is this a LSM?
Seccomp is implemented as a syscall. LSM are security extensions particularly used to implement Mandatory access control but not limited to it.
What would be an example of a minor LSMs?
I am familiar with LSMs from Kconfig but I did not know there was major and minor LSMs
Her slides offer Yama and LoadPin as examples of minor LSMs.
The minor LSMs are Yama, LoadPin, SetsafeID and Lockdown.
Can you highlight some example uses for LSMs for embedded systems?
Hi. Are there any benchmark about the overhead processing and performance?
Hi Vandana, thank you for the exposition. Can more than one LSM run at the same time?