Security Kernels

  • Problem with Multics:
    • Slow, large and complex
    • Hard to achieve performance, generality and security
  • Two trends:
    • UNIX (focus on generality and performance)
    • Security kernels (security, performance and verifiability)
  • Definition:
    • A security kernel is defined as the hardware and software necessary to realize the reference monitor abstraction
  • Systems:
    • Secure Communications Processor (SCOMP)
    • KSOS/PSOS
    • SLAN
    • Secure Ada Target
  • Core principles:
    • Implement security policy (define in MPS)
    • Define a verifiable protection behavior of the system (reference monitor)
    • Implementation must be faithful to the security goals
  • Formal Verification
    • Became the main focus
    • Limits:
      • Can’t detect errors in specification
      • Can’t detect incomplete coverage of the functionality in the specification

MITRE

  • MITRE Project, 1974
  • First security kernel
  • Manage system resources directly
  • Less than 20 subroutines
  • Less than 1 kLOC

Secure Communications Processor (SCOMP)

  • Honeywell, 1983
  • Security kernel-based system
  • Policy: Multics Multilevel Security

Architecture

  • Scomp hardware mechanisms (by Honeywell)
  • Trusted Computing Base:
    • Runs in rings 0,1,2
    • Scomp Trusted OS
      • Kernel (ring 0)
      • Trusted Software (ring 1)
    • Scomp Kernel Interface Package
      • Trusted functions (ring 2)
  • Untrusted
    • Scomp Kernel Libraries (ring 3)
    • Applications

../_images/scomp.png

Fundamentals

  • Similarities to Multics
    • Access control via segments (memory + I/O)
    • Secrecy using Multilevel Security
    • Ring Brackets
  • Differences to Multics
    • Access control/ring implemented in hardware
    • Formal verification
      • Enforcing the policy (‌formal top-level specification)
      • Trusted software outside the kernel is verified using a procedural specification
    • Separate kernel from system API (e.g., file access)
  • Security kernel
    • Manages hardware descriptors (containing address and access rights)

Hardware

  • Complete mediation is implemented in hardware
  • Inspired by Multics
  • Fundamental changes to Multics:
    • Only four protection rings
    • Security protection module (complete mediation)
  • Argument addressing mode
    • Scenario: Lower-privileged process calls higher-privileged routine
    • Goal: Prevent confused deputy
    • Comparable to Multics’ gatekeepers
    • Caller provides memory page with arguments

../_images/scomphardware.png

Security protection module (SPM)

  • Mediate all memory and I/O accesses in the Scomp system
  • Mediate on main system bus
    • Provides access to I/O and memory
    • SPM maps virtual device name to I/O descriptor
  • Memory mediation
    • SPM has hardware cache
  • I/O mediation
    • I/O operation requests a physical address from virtual name
  • SPM and Direct Memory Access
    • DMA: Access memory without CPU (required for performance reasons)
    • Pre-mapped DMA:
      • Driver accesses device/memory
      • SPM authenticates a DMA request once
      • SPM caches request
    • Mapped I/O:
      • Map devices (I/O descriptors) to addresses/registers
      • Device listens on system bus for address
      • Send address to device
      • Device can perform DMA directly
    • Result:
      • Kernel only constructs the I/O descriptor
      • Mediation performed by SPM
      • Drivers can be run outside the kernel
  • AMD/Intel:
    • Adopted four rings but ignored hardware mediation
    • Problem: DMA bypasses CPU (security problem)
    • Added I/O MMUs (inspired by SPM)
    • I/O MMUs mediates I/O access

../_images/iomapping.png

Drivers

  • Scomp runs driver in user-space
  • Workflow
    • Driver performs I/O operations
    • Kernel maps I/O to address
    • SPM uses pre-mapped DMA (SPM only authorizes first request)
    • User process (i.e., driver) can directly address device
  • Advantage:
    • Performance (user process/driver directly communicates with device without the CPU)
    • Stability (drivers often cause kernel fault)

Operating System

  • Security Kernel
    • Ring 0
    • Minimized (10 kLOC, Pascal)
    • Tasks:
      • Memory management
      • Process scheduling
      • Interrupt management
      • Auditing
      • Reference monitoring functions
    • Access Control:
      • Multilevel security (i.e., Bell-LaPadula)
      • Ring bracket policy
      • Discretionary policies
    • Ring transitions
      • 38 gates
      • Similar to modern syscalls (e.g., map segments)
      • Provide argument validation (compare to Multics gatekeepers)
  • Trusted Software
    • Rings 1 + 2
    • Software trusted to not violate security goals (e.g., process loading)
    • Software trusted to maintain security policy correctly (e.g., authentication services)
    • 23 trusted functions (11 kLOC)
  • Kernel Interface
    • Ring 2
    • Comparable to syscall interface
    • Trusted operations on user-level objects
    • Trusted not to violate MLS requirements

User Software

  • Scomp Kernel Interface Package Library
  • Ring 3 (untrusted)
  • Compare to libc/POSIX API
  • Mail Guard
    • Mail client ensuring MLS policy
    • Information not leaked to less secret subjects

Evaluation

  • Complete Mediation
    • Mediate all security-sensitive operations: Hardware enforcement
    • Mediate on all objects: Hardware enforcement
    • Verification: Hardware verification
    • Problem: What about data inside the system?
  • Tamperproof
    • Protect reference monitor: Protection rings
    • Protect TCB:
      • Protection rings and bracket model
      • Leads to integrity (No untrusted code runs in rings 0-2)
      • More complex system than Multics (no more specification in book)
  • Verification
    • Correctness of TCB: Formal verification (using semi-automated methods)
    • Enforcement of security goals: mandatory MLS policy + discretionary bracket policy
  • Result:
    • Verification by DoD’s Trusted Computer System Evaluation Criteria (TCSEC)
    • A1 evaluation level (most secure evaluation level)

Driver Isolation

  • Problem:
    • Scomp in 1983 had complete mediation
    • Later technologies had incomplete mediation (did not use SPM)
    • Faulty drivers are major cause of OS crash
    • 2/3 of code base are extensions
    • 65 - 83 % of crashes in Windows XP are caused by drivers
    • Fixing drivers is infeasible (too rapid growth)
  • Idea:
    • Isolate drivers
    • Use I/O MMUs for mediation
    • Can be more effective
  • Attacks malicious driver:
    • Wipe out kernel memory
    • Overwrite drivers (memory corruption)
  • Design principle: Least Authority

Historical driver isolation

  • Source: Herder et al., 2007, Chapter 4
  • Use trusted kernel + MMU
  • Driver gets own virtual address space
  • MMU denies DMA
  • Kernel copies data between memory segments
  • Process must authorize DMA
    • Explicitly define address space and access rights
    • Pass to other party
  • Approaches:
    • Use better programming language
    • Place driver in virtual machine

Memory Management Unit (MMU)

  • Task: Map virtual to physical addresses (use page tables of process)
  • Driver in virtual address space limits contexts it can access
  • Problem:
    • Driver must access device
    • Device performs DMA
    • Device performs operations important for the OS
    • –> Using CPU is too slow
  • IOMMU:
    • Used for DMA
    • Requires DMA-capable bus
    • Map device address/IO address to physical address

../_images/iommu.png

Fault Isolation for Device Drivers

  • Source: Herder et al. 2009. Fault Isolation for Device Drivers
  • Focus: Isolating untrusted drivers that threaten OS dependability
  • Assumptions
    • Requires IOMMU
    • Blocking of interrupt requests (IRQ): Multiple devices receive an IRQ, one blocks the IRQ due to the PCI standard
    • PCI sharing: Communication over PCI can’t be isolated (only using PCI-E)
  • Limitations
    • MINIX 3: 10-20 % overhead in macro benchmark
  • Overview
    • Based on MINIX 3 (adheres to principle of least privilege/authority)
    • Driver runs as user-mode process
    • Each process has private (IO)MMU-protected address space
    • Policies on driver-basis
    • Reference monitor: Kernel + trusted OS
  • Does this implement a Reference Monitor???

../_images/driver.png

Enforce Least Authority

  • Classify potentially dangerous driver operations:
    1. CPU usage
    2. Memory access
    3. Device I/O
    4. System services
  • Restrict each class
  • Isolation policy:

../_images/driver-policy.png

CPU usage
  • Privileged instructions
    • e.g., resetting page tables
    • Restriction: Put driver in user-space (no privileged operations)
  • CPU time
    • e.g., infinite loop
    • Restriction:
      • Use scheduling
      • Send heart-beats and restart driver if not response
      • Use resource-reservation framework to protect real-time processes
Memory access
  • Memory references
    • e.g., memory corruption
    • Restriction: Address space separation
      • Use hardware MMU
      • Driver gets personal address space
      • Driver accessing outside its space is killed
      • Problem: Page sharing is too coarse for exchanging small data structures
  • Copying/sharing
    • Feature to enable fine-grained sharing
    • Restriction: Run-time memory granting
      • Process can grant address spaces to other processes
      • Store these addresses in grant table (inside kernel (?))
      • Byte-level-granularity
      • Process specifies whether read/write is possible
      • Direct grant and indirect grants possible
      • Results in hierarchical structure
  • DMA
    • Restriction:
      • Driver requests DMA from trusted IOMMU driver
      • DMA into driver’s own address space is allowed

../_images/granting.png

Device I/O
  • Device access
    • e.g., wrong/unauthorized I/O access
    • Restriction: Per-driver I/O policy
      • Drivers have different requirements
      • Each driver gets policy with fine-grained access to the required resources
      • Driver manager reads policy from disk
      • Driver manager informs kernel and trusted OS servers
  • Interrupt handling
    • e.g., hard to implement correctly
    • Restriction: User-level IRQ handling
      • Driver registers for interrupt notifications for a specific interrupt (IRQ) via IRQCTL
      • Kernel verifies the access rights with policy
      • Generic kernel-level handler disables interrupts, masks the IRQ, notifies the driver (HWINT message), re-enable interrupt controller
      • Driver can acknowledge the interrupt using IRQCTL to unmask IRQ line
System services
  • Low-level IPC
    • e.g., unreliable/hostile sender
    • Restriction: Per-driver IPC policy
      • Generally, drivers are not allowed to use IPC
      • IPC can be specified in isolation policy
  • OS services
    • e.g., request routing is privileged operation
    • Restriction: Per-driver call-policy
      • Isolation policy restrict access to kernel calls
      • Protect using POSIX

Evaluation

  • Not really possible to evaluate
  • MPS
    • Each driver has own policy
    • Protection state: Devices + Interfaces
    • Labeling state: Driver-policy
    • Transition state: Not given
  • Reference monitor
    • Complete mediation: Who does mediation?
      • IOMMU/MMU/Kernel (?)
    • Tamperproof: ?
    • Verification: Code+policy not provided