安全操作系统

安全操作系统 中国科学技术大学计算机系陈香兰（0512－87161312） xlanchen@ustc.edu.cn 助教：裴建国 Autumn 2008

第五章操作系统安全体系结构 • 安全体系结构的含义和类型 • 计算机系统的安全体系结构设计的基本原则 • Flask体系、LSM以及Flask在LSM中的应用 • 权能体系

操作系统的设计问题 • 操作系统的测试 • 渗透测试和老虎队分析 • Ethical hacking：正面的黑客行动 • 打补丁 • 可/不可 • 原因 • 旧系统有了新的应用 • 系统在设计时考虑不充分 • 构造安全操作系统时的安全体系结构应当如何？

安全体系结构的含义及类型 • 体系结构设计的主要任务 • 各种不同角度的需求，可能有冲突 • 需要折衷 • 计算机系统的安全体系结构，包括 • 详细描述系统中安全相关的所有方面 • 在一定的抽象层次上描述各个安全相关模块之间的关系 • 提出指导设计的基本原理 • 提出开发过程的基本框架及对应于该框架体系的层次结构

安全体系结构只是一个概要设计，而不能是系统功能的描述安全体系结构只是一个概要设计，而不能是系统功能的描述

要考虑到测评认证的有效性，充分参考 • 可信计算机系统评估准则TCSEC • 通用评估准则CC • TCSEC没有给出“安全体系结构”的定义，但对系统的体系结构和系统设计的文档资料提出了定性的要求，并且给出了顶层规范的定义 • CC也没有

美国国防部的目标安全体系（DoD Goal Security Architecture）把安全体系划分为4种类型 • 抽象体系 • 通用体系 • 逻辑体系 • 特殊体系

计算机系统的安全体系结构设计的基本原则 • 从系统设计之初就考虑安全性 • 应尽量考虑未来可能面临的安全需求 • 隔离安全控制，并使其极小化 • 实施特权最小化 • 结构化安全相关功能 • 使安全相关的界面友好 • 不要让安全依赖于一些隐藏的东西

第五章操作系统安全体系结构 • 安全体系结构的含义和类型 • 计算机系统的安全体系结构设计的基本原则 • Flask体系、LSM以及Flask在LSM中的应用 • Flask • LSM • Flask在LSM中的应用 • 权能体系

一、Flask体系结构

Flask history • In 1992 & 1993, researchers at the NSA and SCC worked on the design and implementation of DTMach, an outgrowth of the TMach project and the LOCK project. • DTMach integrated a generalization of type enforcement , a flexible access control mechanism, into the Mach microkernel. • The DTMach project was continued in the DTOS project. • The DTOS project improved upon the earlier design and implementation work, yielding a prototype that was released to universities for research (e.g.Secure Transactional Resources, DX). From：http://www.cs.utah.edu/flux/fluke/html/flask.html

After the DTOS project, a new joint effort was started by the NSA, SCC, and the University of Utah's Flux project to transfer the DTOS security architecture into the Fluke research OS. • During the integration, the architecture was enhanced to provide better support for dynamic security policies • It was named Flask. • Flask: Flux Advanced Security Kernel • Flask was ported to: • OSKit • Security-Enhanced Linux

论文 • Ray Spencer, et al., The flask security architecture: system support for diverse security policies, in Proceedings of the 8th conference on USENIX Security Symposium - Volume 8. 1999, USENIX Association: Washington, D.C. FLASKFlux Advanced Security Kernel

The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah 参考了Jim Stevens的ppt

Outline • Introduction • Policy Flexibility • Insufficiency of Popular Mechanisms • Related Work • Flask Design and Implementation • Results • Summary • Other Flask object managers • Current Status

Introduction • The notion of “security” in a system is defined in terms of its security policy • A wide range of security policies exist due to the diversity of computing environments • Operating systems must be flexible in support for security policies to accommodate the spectrum of security policies

Supporting policy flexibility is not as simple as just implementing multiple policies • 3 Requirements of Policy Flexibility • Support fine-grained access controls on low-level objects • Propagate access rights according to security policy • Deal with changes in policy over time, including revoking previously granted permissions

Earlier systems provided some mechanisms to implement policy flexibility • Previous systems failed to address all three requirements at once • This paper describes Flask architecture and a microkernel based prototype to demonstrate that policy flexibility is feasible • Flask is based on the concept of mandatory access controls (MAC) • Compare to discretionary access controls (DAC)

What’s ahead • Elaboration on meaning of policy flexibility • Discussion of two popular mechanisms that limit policy flexibility • Flask architecture overview and prototype • Evaluation of Flask prototype

Policy Flexibility • How? • List all known security policies and define flexibility through that list? • Unrealistic • A better definition is needed!

It is more useful to define security policy flexibility by viewing the computer system as an abstract state machine with atomic state transformations • Total flexibility is achieved when security policy knows entire state of system and can affect all operations in the system • Allow/deny operation • Atomically inject handler routines • It is possible to modify the existing security policy and to revoke any previously granted access.

Total flexibility is obviously not possible in a real system • A more realistic approachis to ask what subset of system state and operations are relevant to security • Flexibility of a practical system therefore depends on how complete the set of control operations is and what portion of the state is available to the security policy • Granularity of the controlled operations affects the degree of flexibility because it impacts the granularity at which sharing can be controlled

A policy flexible system must be capable of supporting a wide variety of security policies. • Security policies may be classified by • The need to revoke previously granted access • The type of input required to make access decisions • The sensitivity of policy decisions to external factors like history or environment • Transitivity of access decisions • Revocation is the most difficult characteristic to support

Security policy must deal with policy changes interleaved with execution of controlled operations • Interleaving must be atomic so any controlled operation has a consistent policy • Atomicity is difficult to achieve because access permissions tend to migrate throughout the system • Example: Unix write permissions on a file are only checked when the file is opened. The granted permission is cached in the file descriptor. Changing permissions only affects future open operations. • Migrated permissions are common in capabilities, access rights in page tables, open IPC connections, and other operations in progress

Must make sure entire system knows if a permission is revoked when policy changes • Complicated and potentially expensive • Must identify relevant in-progress operations • Three ways to handle revocation for an in-progress operation • Abort and return error • Restart operation and check permission • Wait for operation to complete • Waiting is not safe because it does not enforce policy and can take an unbounded amount of time

Insufficiency of Popular Mechanisms • We will take a look at: • Capability-Based Systems • Intercepting Requests

Capability-Based Systems • Capabilities are transferable tokens that reference an object and access rights • A capability is an unforgable data structure maps access rights to objects • can be passed around • stored in kernel memory so user can only modify it using an interface • like file descriptors • Example OS implementations are Hydra, KeyKOS, EROS, SCAP, ICAP, and Trusted Mach

Capability mechanisms are poorly suited to providing policy flexibility because they allow the holder of the capability to control the propagation of that capability • Security policy MUST control propagation of access rights to properly implement rules of security policy • Cannot trust the capability holders to implement policy • Hydra and KeyKOS had enhancements to limit propagation, but they were specific to certain policies and very complex

Intercepting Requests • A common approach to add security is to intercept service requests with an additional security layer • May be done in capability or non-capability based systems • Examples: Kernel Hypervisors (not VM!), SPIN, Lava, KeySAFE • Can work at kernel-level or user-level

Limitations • Must expose all abstractions and information flows that the security policy wishes to control • Requires state to be exposed to avoid redundancies and to make sure that policy enforcement mechanisms know what to do • Can only affect an operation as requests pass through the interface

Related Work • Security architecture of Flask is based on DTOS, which had similar goals. • Had mechanisms that were policy independent, but not rich enough to support some policies (particularly dynamic policies) • Used Mach microkernel design to handle revocation of memory permissions (could not handle other permissions) • Generalized Framework for Access Control (GFAC) • Assumes all controlled operations are performed in same atomic operation in which the policy is consulted • Difficult to achieve in a practical system and primary obstacle that Flask had to overcome

Multics • Effectively provided immediate revocation of memory permissions by invalidating segment descriptors • Shows that this problem is not new • Spring • Had a capability revocation method, but didn’t work for migrated permissions

Flask Design and Implementation • Flask prototype is implemented in a microkernel-based multiserver OS • Microkernel isn’t essential though • Only requires a reference monitor • The base system is Fluke • Originally a capability-based system • Modified to meet requirements of Flask architecture consult

In operating systems architecture, a reference monitor is a tamperproof, always-invoked, and small enough to be fully-tested and analyzed module that controls all software access to data objects or devices (verifiable). The reference monitor verifies the nature of the request against a table of allowable access types for each process on the system.

Flask体系结构图 • Object manager– components that enforce security policy • Security server– components that make security policy decisions

Primary Goal: Ensure that subsystems always have a consistent view of policy decisions regardless of how they are made and how they change over time • Secondary goals: application transparency, defense-in-depth, ease of assurance, and minimal performance overhead

Flask provides three primary elements for object managers: • Interfaces for accessing security server decisions • Access – permission between two entities • Labeling – specify security attributes of an object • Polyinstantiation – which member of a set of resources should be accessed for a particular request • Access vector cache (AVC) to cache decisions and minimize performance overhead • Registration service to receive notifications when policy changes

Object managers must define: • a mechanism to assign labels to their objects • a control policy, which specifies how security decisions are actually used and enforced • handling routines that are called when policy changes

Object Labeling • All objects controlled by the security policy are labeled with a set of security attributes, referred to as the security context • Flask provides two data types for labeling objects • Security contexts– variable length strings that can be interpreted by any application or user that understands the security policy, can contain whatever is needed by the security policy and is therefore flexible • SID– fixed size values used as references to security contexts, created for efficiency reasons (cheaper to pass around), security server maintains SID mappings

General Support Mechanisms • Client and Server Identification • IPC calls require the client and server to be identified so the roles are known for a security decision • Caching security decisions • Use AVC to save security decisions because querying the security server is expensive due to IPC and security computation • Coherence is provided by policy change handler routines • Polyinstantiation Support • Security server identifies which instantiation can be accessed by a client

Requesting and caching security decisions in Flask

Polyinstantiation in Flask

安全操作系统

安全操作系统

Presentation Transcript