Linux Security Modules

  • Goal: Enforce mandatory access control
  • LSM Framework: Interface for a reference monitor
  • LSM:
    • Security module
    • Implementing a reference monitor
    • Here: SELinux
  • Motivation
    • Lots of attacks against Windows in 2000
    • MPS is required for a secure OS
    • How to enforce MPS in commercial OS?
    • Idea: Approximate a secure OS
  • Requirements for a secure OS
    • Security policy (e.g. information flow, least privilege)
    • Reference monitor (complete mediation, tamperproof, validation)
    • Formal assurance (OS with reference monitor must enforce policy)

LSM Framework

  • 2001: Secure Linux Project
    • Goal: Refactor security features into Linux
    • e.g., Argus Pitbull, Security-Enhanced Linux (SELinux), AppArmor
    • Problem: All different ideas, which to include?
    • Solution: Linux Security Modules (add another level of indirection)
  • LSM Project:
    • Linux Security Modules
    • Idea:
      • Authorization interface for a security model to act as access control mechanism
      • Interface for any authorization module
    • Module implements policy and the reference monitor
    • Focus: Mediation
    • Current LSMs:
      • Argus Pitbull
      • Security-Enhanced Linux (SELinux)
      • AppArmor
  • LSM as general interface for authorization queries
  • Complete mediation? Not known

Requirements

  • Balance: Kernel developer vs. security developer (speed vs. security/tracing)
  • Challenge: Unify requirements of security projects and minimal impact on Linux kernel
  • Generic
    • Applicable for the normal user
    • Loading a different module is possible
  • Conceptual simple
  • Minimally invasive
  • Efficient
  • POSIX support
  • Support Loadable Kernel Modules (LKMs)

LSM Reference Monitor

  • Goal:
    • Enforce mandatory access control
    • Ensure reference monitor concept
  • Policy defined by module

Complete mediation

  • Add security hook into syscalls
  • Security hook (security check function)
    • Inside syscall (wrap security-sensitive operation)
    • Execute hook before accessing sensible kernel module or similar
    • Hook creates authorization queries to module (invoke function defined in module)
    • Authorization query components:
      • Subject
      • Object (sensitive data type ???)
      • Operation
    • Security module overwrites function
      • Hook default is restrictive
      • Function is pointer (to LSM module function)
      • Function pointer is stored in security->obs table
    • Examples
      • Object types: packet, superblock, process, shared memory, etc.
      • Finer-grained Operations: ioctl, create, getattr, setattr, lock, append, unlink
  • Sensitive data types
    • Used for security labels (see labeling state)
    • Opaque Security Fields
      • Purpose: LSM associates security information with kernel objects (i.e., labels of objects)
      • Implemented as void* pointer (anything can be the value, void pointer has no type, Module should define target)
  • Problem: How to handle object creations before security module was loaded?
  • Problem: LSM unknown whether it implements complete mediation

Tamperproof

  • Goal: Prevent attackers from modifying code/data of LSM/reference monitor (i.e., protection system)
  • Linux: Add function to register/unregister LSMs
  • LSM defines code
  • LSM function pointer points to hooks
    • Problem: Could be changed
  • Idea: Require compiled-in LSM (pointers can’t be changed)

Verification

  • Static analysis
    • Tool: CQUAL
    • Object states: checked/unchecked
    • Time-of-compute-to-time-of-use vulnerability
  • Dynamic analysis

Impact on Linux

  • Changes in kernel
    • Opaque security fields added
    • Security hook function calls inserted
    • Generic security system call added
    • Register/unregister functions for LSMs
    • Capabilities logic moved into security modules
  • Difference from previous DAC
    • Add object types
    • Added authorization for finer-grained operations
    • System labeling: Independent from user
    • Authorization defined by module
    • Policy defined by module

API

../_images/lsm-api.png

Analysis

  • Zhang et al.
  • Static analysis using CQUAL
    • Two states for objects: Checked / unchecked
    • Idea: All objects in security-sensitive operations must be checked
  • Result: TOCTTOU vulnerability
    • Time-of-Check-to-Time-of-Use-Problem
    • Attack: Exploit time between check and use
    • Example: Check file for permissions/change file/use file
  • Overhead (worst case): 5 %

SELinux

  • Reference monitor to enforce mandatory access control
  • Components
    • Authorization module (build authorization queries)
    • Policy store
  • Fine-grained control of system resources
  • Philosophy: ‌Inevitability of Failure
    • Security management in application-space is insufficient
  • History:
    • 1980s: Mach microkernel retrofitting
    • 2000: Start of SELinux
    • Motivated by the security kernel design philosophy
  • Design of the MPS
    • Problem: Classical integrity un-achievable (due to too many exceptions)
    • Confine root processes (tamperproof)
    • Least privilege (verifiability)
  • Problem: Tens of thousands rules necessary for standard Linux (significant effor)
  • Problem: Get SELinux policy working/usable

../_images/selinux.png

Essentials

  • Type
    • Group of objects (files/directories)
    • Based on security sameness
    • e.g., passwd_exec_t, etc_t
  • Domain
    • Process runs in a domain
    • Domain is assigned types it can access
    • e.g., initrc_t
  • Role
    • Define domains and types a user/process can access
    • e.g., user_r, admin_r
    • User/process can transition between roles
    • Transition rules defined in SELinux policy
  • Identity
    • Identity is applied to user account
    • Usually, does not change
    • e.g., alice
    • Identities are assigned roles
  • Security Context
    • Comparable to label (assigned to each object/process)
    • identity:role:domain
    • identity:role:type
  • Type Enforcement (TE)
    • Principle of Least Privilege
    • Control access to system calls/domains/types
  • Role-based Access Control (RBAC)
    • Users are assigned to roles
    • Roles are assigned to domains/types
  • SELinux Policy
    • TE + RBAC = SELinux Security Model
    • Define rules
    • Policy expresses an MPS

Protection State

  • Syntax: <access_vector> <subject_t> <object_t>:<object_class> <permission_set>
  • Default: Access denied
  • Access Vector (access_vector):
    • allow (explicitly grant access)
    • neverallow
      • Explicitly disallow access
      • Invariants
      • If violated, policy does not compule
    • auditallow (log when granted)
    • dontaudit (do not log deny (eliminate expected denies))
  • Types (subject_t, object_t):
    • *: All types
    • self: Same source
    • ~: Complement set
    • {}: Multiple (set)
  • Class (object_class):
    • {}, *, ~ allowed
    • e.g., file
  • Permissions (permission_set):
    • Operations/permissions on that type
    • {}, *, ~ allowed
    • execute_trans: Execution allowed with transition
  • Examples
    • allow user_t passwd_t:file execute: Allow role user_r to execute all files from the passwd_t type
    • neverallow ~{user_t} passwd_t:* *: Prohibit every access to passwd_t type except user_t

Labeling State

  • Syntax: type_transition source_type target_type : class default_type;
  • Must be allowed by TE policy
  • Default: Same state as creator
  • Class: file-related
    • New object type
    • Process from source creates new file-related object in directory of target
    • Object has default label
  • Example:
    • type_transition passwd_t tmp_t:{file lnk_file} passwd_tmp_t: File/link created by passwd_t in tmp-dir gets type passwd_tmp_t

Transition State

  • Syntax: type_transition source_type target_type : class default_type;
  • Must be allowed by TE policy
  • Class: process
    • Domain transition
    • Process from source executing target transitions to default
  • Must be allowed by TE policy
  • Examples:
    • type_transition user_t passwd_exec_t:process passwd_t: User executing password program transitions to passwd_t

Example: setuid

  • Normal user should run privileged process (e.g., passwd)
  • Protection state:
    • allow user_t passwd_exec_t:file execute
    • allow user_t passwd_t:process transition
    • allow passwd_t shadow_t:file {read write}
  • Transition state:
    • type_transition user_t passwd_exec_t:process passwd_t

Deployment

  • Install policy in kernel
  • Make services aware
  • Maintain policy
    • System is dynamic
    • Adapt to changes
    • Reconfigure policy
  • User-space services
    • Authentication
    • Access control
    • Configuration

Authentication

  • Example: sshd (network)
  • Services must create a SELinux subject context for a user login
  • Problem: Services must work with SELinux
  • Solution: Pluggable Authentication Module (PAM)
    • API for central authentication
    • Comparable to GITZ (?)

Access control

  • Example: Databases, Browsers
  • Problem:
    • PostgreSQL accesses server
    • Server may leak user information
  • Client-side software implements SELinux user-space library
  • Use Access Vector Cache for faster access control

Configuration

  • Example: Policy change/recompile
  • Goal: Prevent attacker from controlling system policy at load
  • Use Policy Management System
  • How does this work???