1 / 25

Chapter 6

Security Kernels. Chapter 6. Chapter Overview. Description Secure Communications Processor (Scomp) Architecture Hardware Trusted Operating Program Kernel Interface Package Applications Evaluation Gemini Secure Operating System Summary. Security Kernels.

Télécharger la présentation

Chapter 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Security Kernels Chapter 6

  2. Chapter Overview • Description • Secure Communications Processor (Scomp) • Architecture • Hardware • Trusted Operating Program • Kernel Interface Package • Applications • Evaluation • Gemini Secure Operating System • Summary

  3. Security Kernels • Efforts from the 70s and early 80's” • SCOMP (Honeywell) • Gemini Secure OS (GEMSOS) • Based on Provably secure OS design: • Secure Ada Target (SAT) (Honeywell) • LOCK (Secure Computing) • Kernelized Secure OS (KSOS) (Ford Aerospace and Communications) • Secure LAN (Boeing) • etc.

  4. The Security Kernel • MITRE, 1974, 20 subroutines, 1000 SLOC • Showed the what and the how. • Focus became verification • Three core principles: • Implement a specific security policy • Define a verifiable protection behavior of the system as a whole • The implementation must be shown to be faithful to the security model's design

  5. Secure Communications Processor (Scomp) • Kernel-based system • Designed to implement Multic's MLS requirements. • Original idea was to build an emulator to allow execution on an ordinary OS (UNIX). • Ended up with new API that provided the necessary security.

  6. Problems with the emulation • Incompatible representations between the two systems: • UNIX I/O copies data directly to application's address space, • SCOMP maintains data in individually managed segments to which access must be authorized. • There are Unix mechanisms that are inherently insecure: for example fork and exec share file descriptors, thereby leaking data and authorization problems.

  7. Scomp Architecture

  8. SCOMP Architecture notes • Accesses to protected resources are mediated using an MLS policy: • App requests hardware descriptor sufficient to access resource. • If granted, security kernel builds the descriptor (object+permissions) and returns a reference • Isolation/tamperproofing provided by ring mechanism. Rings and transitions are implemented in hardware. • Verification was part of the process.

  9. SCOMP Hardware 1 • Based on Multics design with two key changes: • Only four rings, all in hardware. • Argument addressing mode prevents confused deputy problem. • Hardware includes a security protection module (SPM). • It mediates the main system bus (peripherals and memory). • Virtual memory interface unit uses SPM to convert between virtual and physical addresses

  10. SCOMP Hardware 2 • Each process includes a descriptor base root: • References memory and I/O descriptors • Used for mediating memory and I/O references. • DMA is authorized on a per-transaction basis. • I/O descriptors are built by kernel. • Hardware does all authorizations. • Drivers are not part of kernel! (more efficient and secure)

  11. SCOMP Security Protection Module

  12. Scomp Trusted Operating Program (STOP) • Three components: • A security kernel. (ring 0) • A set of trusted software • A kernel interface package for user applications.

  13. SCOMP Trusted Operating Program Security Kernel • Memory management, process scheduling, interrupt management, audit and reference monitor. 10K SLOC mostly in Pascal. • Objects consist of processes, segments, devices, identified by a unique 64 bit id. • Access control similar to Multics, but ring brackets allow for owner/group/others • 38 gates to enter ring 0

  14. SCOMP Trusted Software 1 • Two types: • Trusted not to violate system or integrity goals: e.g. secure loader is trusted to load a process for any subject that ensure correct enforcement of information flows. • Trusted to maintain security policy correctly: e.g. user authentication. • 23 processes implement trusted functions: 11K SLOC in C

  15. SCOMP Trusted Software 2 • Three kinds of user processes: • Trusted user processes: login, dac management, mandatory level selection, process management. • Trusted operation services: system management, logging, startup, shutdown, set time, etc. • Trusted maintenance services: modify system data, install new program versions, etc. • Invoked through a secure communications path directly by the user.

  16. Scomp Kernel Interface Package (SKIP) 1 • Uniform interface for user applications to access trusted functions. • Two parts • SKIP functions • SKIP libraries

  17. Scomp Kernel Interface Package (SKIP) 2 • SKIP functions do trusted operations on user level objects • Files via a hierarchical file system • Process management • Concurrent I/O through an event mechanism • Allowed to manipulate system state, so trusted not to violate MLS requirements, like trusted software. • In ring 2, invoked via gates

  18. SCOMP Kernel Interface Package (SKIP) 3 • SKIP Library runs in level 3, provides interface to SKIP functions. • There are applications to access files, modify file contents, manage file hierarchy. File operations are authorized based on requester's sensitivity level and ring number, thus sensitivity level is nondecreasing from the root. • Library also provides I/O, and the device drivers are part of the library. Handlers are also run in the library

  19. Scomp Applications • Unix?? • Mail guard • Secure Office Management System

  20. Scomp Evaluation 1: Complete Mediation • How does the reference monitor interface ensure that all security operations are mediated correctly? • All mediation done in hardware • Does the reference monitor interface mediate security-sensitive operations on all system resources? • Initial access to file data depends on access to I/O • How do we verify that the reference monitor provides complete mediation? • Hardware.

  21. Scomp Evaluation 2: Tamperproof • How does the system protect the reference monitor, including its protection system, from modification? • Protection rings, but not complete, due to need. • Does the protection system protect the trusted computing base programs? • Also protection rings

  22. Scomp Verification: Verifiable • What is the basis for the correctness of the system's TCB? • Verified with Formal analysis tools • Does the protection system enforce the system's security goals? • Also verified for correctness.

  23. Gemini Secure Operating System

  24. GEMSOS Security Kernel Layers

  25. Summary

More Related