第4章 操作统安全体系结构.pptVIP

第4章 操作系统安全体系结构 4.1 概述 安全问题的暴露 解决问题的方法：1、在现有系统上打补丁来排除；2、无法在原有系统上进行补救，只有重新改造系统，甚至重新设计系统 造成的原因： 1、由于旧系统增加了新的应用（无法预测） 2、系统设计时考虑不充分（缺乏有效的系统安全体系结构所致） 安全体系结构的含义及内容 使系统在实现时对各项要求，如安全性要求、性能要求、可扩展要求、容量要求、成本要求等折中考虑，是体系结构的主要任务 安全体系结构 1. 详细描述系统中安全相关的所有方面 2. 在一定的抽象层次上描述各个安全相关模块之间的关系 3. 提出指导设计的基本原理 4. 提出开发过程的基本框架及对应于该框架体系的层次结构。安全体系按层次结构进行描述，包括两个阶段：概念化阶段、功能化阶段 安全体系的描述 系统开发的概念化阶段：安全概念的最高抽象层次的处理，如系统安全策略等 系统开发的功能化阶段：系统体系确定时，进一步细化安全体系以反映系统的结构 安全体系结构只能是一个概要描述,而不能是系统功能的描述 安全体系结构不应该限制不影响安全的设计方法 开发安全操作系统时应参考”可信计算机系统评估准则”(TCSEC)及”信息技术安全性通用评估准则”(CC) DGSA的安全体系 抽象体系: 描述安全需求,定义安全功能及它们提供的安全服务,确定指导原则和基本概念 通用体系: 定义系统的通用类型及使用标准,规定系统的指导原则，在已有的安全功能和安全服务配制上，定义系统分量类型及相关安全机制。并应说明不兼容导致的安全强度的退化。 逻辑体系:是满足某个假设的需求集合的一个设计，显示把通用体系应用于具体环境时的基本情况,是假想体系，不是实际体系 特殊体系: 表明如何把所有被选择的信息安全分量和机制结合起来，针对一个特殊系统的安全需求，描述接口、分量、标准、性能、开销及如何结合 安全体系结构设计的基本原则 从系统设计之初就考虑安全性 在设计系统体系结构的同时就考虑安全体系结构 应尽量考虑未来可能面临的安全需求 使未来系统实施安全增强时，开销小。但应注意： 1. “预想的”安全问题不能太具体。 2.从问题类的角度理解安全问题，不是针对具体问题。 3.特别关注安全策略的定义 机制经济性原则 应极小化系统内部与安全相关部分的复杂性及规模，安全系统必须限制规模。但应注意: 1.安全机制尽量简洁。 2.数据隔离应适当 失败-保险默认原则 访问判定应建立在显式授权而不是隐式授权的基础上 特权分离原则 高度的分离可以带来安全性的提高,但也导致效率下降 最小特权原则 硬件特权极小化与软件特权极小化 最少公共机制原则 把由两个以上用户共用和被所有用户依赖的机制数量减到最小 完全仲裁原则 只有得到授权的客体才被允许访问 开放式设计原则 在公开环境中增强安全机制的防御能力 心理可接受性原则 用户界面设计得要易于使用和充分友好 4.2 Flask体系结构 Internet的异质互连特征要求系统支持安全策略的可变通性 可变通性要求系统支持底层客体的细粒度访问控制；确保权限增长与动态安全策略的一致性；提供能撤消以前授予的访问权限的机制 Flask系统来源于以前的DTOS系统原型,支持动态安全策略,使策略可变通性的实现成为可能 Flask结构将机制与策略相分离，由一个安全策略服务器和一个微内核及客体服务器框架组成，前者制定访问控制策略，后者执行访问控制策略，该结构基于微内核但不依赖微内核 策略可变通性 基本思想：将系统抽象成状态机，执行原子操作完成一个状态到另一个状态的转换，安全策略被原子的插入到系统的操作执行中，一个系统提供整个系统安全策略可变通性。该模型中，若当前状态包括系统历史，则安全策略用全部当前状态作决定，判断操作的执行与否 受限思想（实现）： 当前状态区分为与安全相关及不相干部分，系统的可变通性只与相关状态完整性及它们的控制操作有关。这种思想允许存在一些安全控制外的操作及一些系统状态。 支持策略可变通性机制要求： 1.能撤回以前授予的权限。 2.作访问决策所需的输入类型 3.影响决策的外部因素（如历史）。 4.访问决策的可传递性支持 策略改变：系统要保证策略改变与控制操作的交叉使用时必须保持原子性。 策略撤消：系统要保证已在系统中移动的授权真正收回 当一个正运行的操作已检查过许可权，撤消机制常用三种方法，终止、重启、不管 特殊微内核特征 Flask采用类似Fluke方法处理内核。 Fluke中将每个活动对应的内核对象与一块物理内存对应，每个内