Analyzing the Overhead of File Protection by Linux Security Modules

Abstract

Over the years, the complexity of the Linux Security Module (LSM) is keeping increasing (e.g. 10,684 LOC in Linux v2.6.0 vs. 64,018 LOC in v5.3), and the count of the authorization hooks is nearly doubled (e.g. 122 hooks in v2.6.0 vs. 224 hooks in v5.3). In addition, the computer industry has seen tremendous advancement in hardware (e.g., memory and processor frequency) in the past decade. These make the previous evaluation on LSM, which was done 18 years ago, less relevant nowadays. It is important to provide up-to-date measurement results of LSM for system practitioners so that they can make prudent trade-offs between security and performance.This work evaluates the overhead of LSM for file accesses on Linux v5.3.0. We build a performance evaluation framework for LSM. It has two parts, an extension of LMBench2.5 to evaluate the overhead of file operations for different security modules, and a security module with tunable latency for policy enforcement to study the impact of the latency of policy enforcement on the end-to-end latency of file operations.In our evaluation, we find opening a file would see about 87% (Linux v5.3) performance drop when the kernel is integrated with SELinux hooks (policy enforcement disabled) than without, while the figure was 27% (Linux v2.4.2). We found that performance of the above downgrade is affected by two parts, policy enforcement and hook placement. To further investigate the impact of policy enforcement and hook placement respectively, we build a Policy Testing Module, which reuses hook placements of LSM, while alternating latency of policy enforcement. With this module, we are able to quantitatively estimate the impact of the latency of policy enforcement on the end-to-end latency of file operations by using a multiple linear regression model and count policy authorization frequencies for each syscall. We then discuss and justify the evaluation results with static analysis on our syscalls' call graphs, which is call string analysis enhanced with execution order analysis.Conference'17, July 2017, Washington, DC, USA Wenhui Zhang * This is carried out using LMBench2.5 executed on a 700 MHz Pentium Xeon computer with 1 GB of RAM and an ultra-wide SCSI disk. † This is carried out using LMBench2.5 executed on a 333MHz Pentium II with 128M RAM. ‡ This is tested with LMBench2.5 on 6th Generation Intel® Core™ i7-6500U 2.50 GHz processor with 2 cores, at 1,442MHz each

Secure Namespaced Kernel Audit for Containers

“…It is difficult to precisely measure LSM overhead [68]. In general, there exist two sources of overhead when performing audit (or other policy enforcement) through LSM: hooking and execution.…”

XFilter: An Extension of the Integrity Measurement Architecture Based on Fine-Grained Policies

“…SMACK may also be absent from the support list. Additionally, due to their lower impact on the file loading overhead, many system installations choose AppArmor or TOMOYO instead of SELinux [7,8]. Additionally, SELinux implements MAC policies by means of contexts composed of users, roles, and types [9].…”

A Practical, Lightweight, and Flexible Confinement Framework in eBPF

“…Enforcement hooks serve as checkpoints for security enforcement over specific access categories, while bookkeeping hooks enable a se-curity module to maintain stateful information about subjects and objects on the system. LSM hooks are not considered to be static, and often change between kernel versions as new hooks are implemented and both new and existing hooks placed into various kernel functions [158]. The eventual goal of the LSM framework is to provide complete mediation over kernel security events, however this is an evolving process and no formal verification exists to prove the security of LSM hooks [60].…”

“…In the Complaining case, BPFBox and BPFContain significantly outperform AppArmor, a fact which can be attributed to inefficiencies in AppArmor's logging mechanism, which relies on the kernel's audit framework. The ring buffer maps used by BPFBox and BPFContain are known to exhibit comparatively less overhead [103,157,158]. Additional overhead may also arise due to differences in how…”