Exercises

Programming exercise

01 Namespaces

  • Process
    • Concept for an executable
    • Gets virtual memory (mapped to physical)
    • Share resources
  • Isolation
    • Virtual machines
      • Isolate complete OS
      • Own kernel and applications
      • Isolation enforced by Hypervisor
      • Disadvantage: Heavy weight (kernel)
    • Container
      • Isolate processes
      • Use namespaces for access
      • Re-use host kernel
  • Linux Namespaces
    • Abstraction of resources (box holding resources)
    • Process belongs to one namespace per type
    • Create new namespace: unshare
    • Namespaces
      • Unix Timesharing System (hostname, domain)
      • IPC
      • PID (process number, PID 1 in container)
      • User (isolate user/group IDs, use mapping to host)
      • Mount (isolate mount points, change root)
  • Change root
    • chroot: Not for security reasons, only pathname resolution
    • pivot_root: Securely change root (then unmount old root)
  • Workflow:
    • Create namespaces
    • Mount new file system
    • Change user/group IDs
    • Mount special files (dev/tmp/proc)
    • Change root
    • Fork container process
    • Set hostname
    • Execute entrypoint

../_images/namespaces.png

02 Securing container

  • More isolation:
    • Environment variables (e.g., USER, Tokens, Paths)
    • Scheduling information (/proc/sched_debug)
  • init process
    • PID 1
    • Collects zombies (child whose parent died)
    • Container root process is bash (doesn’t collect children)
    • Use container-aware init process (e.g., tini, dumb-init)

Resource restriction

  • Isolate resources
  • nice: process priority
  • setrlimit:
    • Restrict resources for process and children
    • But consumption is not accumulated
    • Child may use as much as parent
  • cgroups:
    • Fine-grained, complex limitation
    • Requires root
    • Uses controllers (manage groups using directories)

Syscall restriction

  • Filter syscalls
  • seccomp
  • Based on Berkeley Packet Filters
  • Library libseccomp (easier to use)
  • Features
    • Masking of arguments
    • Creating black- and whitelists

Capability restriction

  • Linux 2.2 introduced capabilities
  • Each thread has sets of capabilities (basically bitmasks)
  • Sets:
    • Bounding set \( B \)
      • Superset for capabilities a thread can add to inheritable and permitted sets
    • Permitted \( Prm \)
      • Capabilities a thread can have
      • Superset for the effective capabilties
    • Effective \( Eff \)
      • Capabilities a thread has (used for permission checks)
      • File capability is single bit
    • Inheritable \( Inh \)
      • Not preserved across execve (non-root)
    • Ambient \( Amb \)
      • Preserved across execve (non-root)
  • Roles:
    • Child process \( C \)
    • Parent process \( P \)
    • File \( F \)
  • Rules
    1. \( B\supseteq C_{Inh} \)
    2. \( B\supseteq C_{Prm} \)
    3. \( C_{Prm}\supseteq C_{Eff} \)
    4. \( C_{Prm} = (P_{Inh} \& F_{Inh}) | (F_{Prm} \& B) \) (6.)
    5. \( C_{Eff} = F_{Eff} ? C_{Prm} : C_{Amb} \)
    6. \( C_{Amb} = (\text{file is privileged}) ? 0 : P_{Amb} \)
    7. \( C_{Prm} = (P_{Inh} \& F_{Inh}) | (F_{Prm} \& B) | C_{Amb} \)
    8. \( C_{Eff} = F_{Eff} ? C_{Prm} : C_{Amb} \)
    9. \( C_{Inh} = P_{Inh} \)
  • Drop capabilities
    • libcap
    • Drop specific capabilities
    • Problem: Inside container we are root

03 SGX SDX

  • Use wrapper code edger8r
  • Enclave metadata file
  • Enclave description file
  • enclave_u
    • Untrusted side (call Untrusted Runtime System)
    • Marshal arguments
  • enclave_t
    • Trusted side (called from TRTS)
    • Unmarshal arguments
  • Untrusted Runtime System
    • Transition into enclave
    • Provides ECALLs
  • Trusted Runtime system
    • Provides OCALLs
  • Libraries
    • No unsafe calls
    • No system calls
    • Use SGX libraries

Paper analysis

Evaluating Software (In)Security

  • Jain et al. (2017)
  • Topic
    • Measure software security/TCB complexity
    • Changing code base increases risk for new bugs
    • Which metrics are useful?
    • Goal:
      • Prevent security issues
      • Prove absence of bugs
  • Current standard
    • Formal verification: Too complex
    • Lines of code: Unreliable
      • Lines of code weakly correlates with vulnerabilities
      • Bug does not imply vulnerability
    • Testing
      • Auditing prevents bugs
      • Unit tests find obvious bug (not necessarily vulnerabilities)
    • Bug finding tools
  • Contribution: Features of code to train a classifier (static analysis)
  • Propose metrics/features:
    • Lines of code
    • Common Vulnerability Scoring System (CVSS)
    • Radial Attack Surface Quotient (RASQ)
    • Number of functions/variables
  • Classes to predict:
    • Network attacks
    • Buffer overflows
  • Dynamic analysis more effective
    • Detect vulnerabilities in runtime
    • Monitor program behavior
    • Advantage if code base is inaccessible
  • Discussion:
    • Feature set provided but no classifier

Kernel Attack Surface Reduction (kRazor)

  • Kurmus et al. (2014)
  • Problem:
    • 90 % of kernel functions are not used by average network daemon
    • Unused kernel functions mean unnecessary large attack surface
  • Contribution: Limit attack surface by reducing number of kernel functions at run-time (kRazor)
  • Definition attack surface:
    • Subgraph of kernel call graph
    • Entrypoints are accessible to adversary
  • Approaches:
    • Static:
      • Micro-kernel (lack of compatibility, e.g., MINIX 3)
      • Kernel specialization (remove sys-calls from kernel, re-compile kernel for application)
    • Dynamic:
      • System call monitoring
      • System-call-based process sandboxing (whitelist system calls, kRazor is generalalization of this)
  • kRazor:
    • Run-time
    • Complete mediation (syscalls are objects)
    • Add hooks to each syscall
    • quantifiable + non-bypassable
    • Learn set of system calls used by application
    • Create set of allowed kernel functions (expand by using related functions, e.g., read and write)
    • Option for violations:
      • Kernel Oops
      • Logging
  • Metrics for attack surface:
    • LOC
    • Cyclomatic complexity
    • CVE-based (1 if function has security vulnerability, 0 otherwise)
  • Discussion:
    • Least Privilege Policy
    • Problem: No guarantee that all system calls are traced (edge case)
    • No statistics in prevented attacks

TrustVisor

  • McCune et al. (2010)
  • Related lectures: SGX
  • Provide isolation for security-sensitive code parts (PALs)
  • TrustVisor is a hypervisor
  • Features:
    • Code integrity (memory region is checked)
    • Data secrecy (memory is encrypted)
    • Data integrity
    • Execution integrity
  • Marshal parameters when call enters a PAL
  • Split code into sensitive and non-sensitive parts
  • Use Dynamic Trust for Measurement (hardware component)
    • Chain of Trust
  • Emulate TPM for each PAL
  • Memory encryption is not possible, use memory isolation
  • Trap into hypervisor if PAL is accessed

From L3 To seL4

  • Elphinstone et al. (2013)
  • Related lectures: Security Kernels, VMM
  • seL4 is security-microkernel
  • Microkernel principles:
    • Minimality (and no policy in kernel)
    • IPC performance
    • Real-time computing (?)
  • Development since L4:
    • Synchronous messaging replaced (support multi-threaded application)
    • Physical registers to virtual registers (improve portability)
    • Long IPC removed (could trigger page faults)
    • Thread IDs replaced by port-like endpoints (improve confidentiality)
    • IPC timeouts restricted to 0 (poll) or infinity (block) (adapt to practice)
    • Communication control (chief-and-clans) remove (contradicting goal of policy-freedom)
  • Problem of scheduling:
    • Scheduling often implemented in kernel
    • Contradicts goal of policy-freedom
    • Often used: Hard-priority round-robin (fixed time-slices)
    • Scheduling in user-space too slow (bottleneck is IPC)
  • Minimality
    • Important
    • Formal verification is easier with minimality
    • But it influences design decisions (multi-threading, complex scheduling, standard calling convention)
    • Authors do not think performance suffers from the new design decisions

Graphene-SGX

Hardware Is The New Software

Lecture Questions

01 Introduction

  • What are the problems with adversary code on your machine?
  • What can an adversary do?
  • What can you do to avoid executing adversary-controlled code?
  • What is the problem with running code from benign sources?
  • How would “good” code look like?
  • Who may be responsible for software and systems security in computing environments?

02 Threats & Security Principles

  • Why is Protection State insufficient to enforce security?
  • What do we need to achieve necessary controls?
  • How do we know the policy expresses effective goals?
  • How do we know the enforcement mechanism will enforce policy as expected?
  • How can you use an MPS to control use of bad code?
  • How can you use labeling state to control bad code?
  • What defines correct code?
  • What defines correct policy?
  • What about objects created by these processes?
  • How can you use labeling state to prevent good code from going bad?
  • What if good code needs to access some adversary-controlled resources?
  • How do we achieve this change with the MPS?
  • Is it possible to launch processes with more permissions than the invoker with MPS?

03 Multics

  • „If people just used Multics, we would be secure. UNIX and Windows are insecure.“ What is the basis for these statements?
  • Does Multics implement a Mandatory Protection System enforced by a Reference Monitor?
  • Does Multics satisfy the evaluation criteria?
  • What were the security goals for Multics?
  • Are brackets a Mandatory Protection System?
  • Multilevel Security a MPS?

04 LSM

  • How do we add MAC enforcement effectively to a commercial OS?
  • What is required to be a secure OS?
  • Which Linux data types are sensitive?
  • What to do about object creation before the security module is loaded?
  • How do we know LSM implements complete mediation?
  • How is LSM code protected?
  • How is LSM data protected?
  • Where to exactly place the hooks?

05 Integrity

  • What is data integrity?
  • What do we need to do to ensure data integrity?
  • What do you expect for integrity of software?
  • How does software integrity impact data integrity?
  • How to compute least privilege?
  • Can we use it to verify a policy is secure?
  • What do we do if a system needs an information flow from low integrity to high?
  • Assured Guards: What does “fully assured” mean?
  • What could you do to avoid self-revocation?
  • But shouldn’t programs at least know where they expect to receive UDIs?

07 Security Kernels

  • What are the advantages of such an approach?
  • What are the limits of verification?
  • Why is Scomp appropriate to support such an application?
  • [Drivers in user space] how is this possible in Scomp?
  • [Complete Mediation] For files? For mail data? What about DMA operations?
  • Why are systems like Scomp not the norm?
  • Why are drivers a problem?
  • How do we reduce such problems?
  • Can we somehow fix drivers?
  • What exactly does an MMU do?
  • Who does Mediation?
- Are they all reference monitors?
  • Does this approach satisfy reference monitor concept?
  • Does it implement a MPS?
  • So why don’t build systems with such a design?
  • What could be transferred to current systems?

08 VMM

  • Do these work for modern OSes? Are there alternatives?
  • How does VM isolation differ from OS isolation?
  • What are the trust model issues when comparing Type I and Type II?
  • How does a VM System improve the ability to achieve reference monitor guarantees?
  • What components constitute the VAX VMM reference monitor?
  • How is the protection state modified?
  • How do we implement a reference monitor and a validation mechanism for theses systems?
  • At what granularity control should be enforced?
  • How do we configure access control for containers?
  • Can we use VM isolation to prevent compromise of applications by malicious OS?