操作系统虚拟化之安全体系结构

安全体系结构概述

安全体系结构定义：安全体系结构描述的是一个系统如何组织成一个整体以满足既定的安全性要求

安全体系结构组成：
1. 详细描述系统中安全相关的所有方面。这包括系统可能提供的所有安全服务及保护系统自身安全的所有安全措施，描述方式可以用自然语言，也可以用形式语言。
2. 在一定的抽象层次上描述各个安全相关模块之间的关系。这可以用逻辑框图来表达，主要用以在抽象层次上按满足安全需求的方式来描述系统关键元素之间的关系
3. 提出指导设计的基本原则。根据系统设计的要求及工程设计的理论和方法，明确系统设计各方面的基本原则。
4. 提出开发过程的基本框架及对应于该框架体系的层次结构。描述确保系统安全需求的整个开发过程的所有方面

安全体系结构作用：
安全体系结构在整个开发过程中必须扮演指导者的角色。①、要求所有开发者在开发前对安全体系结构必须达成共识; ②、在开发过程中自觉服从于安全体系结构; ③、在工程实现阶段也必须在体系结构的指导原则下进行工作。
因此：①安全体系结构应该只是一个概要设计，而不是系统功能的描述。②安全体系结构应该有模块化的特性。

七个设计原则：
1. 从系统设计之初就考虑安全性:因此在考虑系统体系结构的同时就应该考虑相应的安全体系结构。
2. 应尽量考虑未来可能面临的安全需求
3. 实现安全控制的极小化和隔离性:并不是建立的控制越多就越安全，最小开销达到最大的安全系。安全组件与其他组件隔离开来。
4. 实施极小特权 ：不应该让某些用户具有过高的权限。
5. 安全相关功能必须结构化：具有一个好的体系结构，安全相关的部分能够被确定，总体上能够很快对系统检查。对安全功
6. 清晰的易于规范的接口。
7. 使安全性能“友好” ：增加安全性不要给合法用户带来负担
8. 使安全性不依赖于保密：可以告诉用户摄像头在哪，可以告诉用户消防器在哪。

---

GFAC安全体系结构

GFAC假设所有访问控制策略都可以视为由安全属性构成的安全规则的集合，因此定义三个概念：
- 权威(Authorities)：是一个授权个体，它可以定义安全策略、确定安全信息和给安全属性赋值；

• 安全属性(Attributes)：用于访问控制决策的主体、客体的属性；

• 规则(Rules)：对安全属性和其它安全信息之间相互关系的形式化描述，这种关系是安全策略的反映。规则由权威制订。

GFAC中将安全属性和其它访问控制数据称为访问控制信息(ACI, AccessControl Information)，而将实现系统安全策略的规则称为访问控制规则(ACR, Access Control Rules)。

GFAC将访问控制分为两部分：
AEF(Access controlEnforcement Facility)访问控制实施部分。它依据ADF的决策结果，控制访问是否进行。

ADF(Access controlDecision Facility)访问控制决策部分。它实施系统的各种安全策略和元策略（综合各安全策略的判定结果后决定是否允许访问）。ADF在进行决策时，需要参考的访问控制信息（描述主、客体的安全属性）和访问控制规则（描述安全属性之间的关系）保存在ACI和ACR中。

---

FLASK体系结构

FLASK体系结构的特点：1）支持多种安全策略；2）可实现细粒度的访问控制；3）能够确保访问权限的授予与安全策略保持一致；4）能够撤回先前已授予的访问权限。

FLASK体系结构由客体管理器OM和安全服务器SS组成。（1）OM负责实施安全策略（2）SS负责安全策略决策。
FLASK描述了客体管理器和安全服务器之间的交互，以及对它们内部组成部分的要求。

OM的组成：
- 第一，为客户端提供访问决策、标记决策和多实例化决策的接口。
- 访问决策确定一个访问是否被允许。
- 标记决策确定应该授予客体何种安全属性。
- 多实例化决策确定当前多实例化资源中哪一个成员应该被访问。
- 第二，提供一个访问向量缓冲器AVC (Access Vector Cache), 暂时缓存访问决策结果，以提高系统效率。
- 第三，提供接收和处理安全策略变动通知的能力。

安全服务器SS的基本功能：
安全服务器需要提供安全策略决策、保持SIDs和安全上下文之间的映射、为新创建的客体提供SIDs、提供成员客体的SIDs、控制OM的AVC。此外大多数SS的执行会对载入和改变策略提供相应的功能。
除了OM中的AVC机制以外，对SS提供一个自己的缓存机制保存访问计算的结果，可以缩短它的反应时间。

LSM框架:

LSM的特点：
（1）真正通用，使用不同的安全模型的实施仅仅是加载不同的核心模块；
（2）概念上简单，最小的扩散，有效；
（3）能够作为一个可选安全模块，支持现有的POSIX.1e权能逻辑。
另一方面，各种不同的Linux安全增强系统对Linux安全模块（LSM）提出的要求是：能够允许他们以可加载内核模块的形式重新实现其安全功能，并且不会在安全性方面带来明显的损失，也不会带来额外的系统开销。

LSM的5处修改：

【内核关键数据结构的修改 ，钩函数的调用 ，新增安全系统调用 ，安全模块管理 ，独立capability模块】
（1） 在特定的内核数据结构中加入安全域：加载时候要赋值，卸载时候要释放，void*security
（2） 在内核代码中的管理域和实现访问控制的关键点介入对钩子函数的调用:原来的内核里面加入钩函数，LSM提供了153个钩函数。
（3） 加入一个通用的安全系统调用：可以灵活扩展——提供新的系统调用
（4） 提供函数允许内核模块注册为安全模块，或者注销一个安全模块
内核初始启动时是一般系统的状态，加载的是dummy模块（支持传统的超级用户模式）
主模块管理
加载：register_security:实现security_ops和其引用的钩函数对应。该机制用于设置主模块，负责每个钩函数函数的最终决策。
卸载：unregister_security:返回初始状态。
模块堆栈管理：mod_reg_security，mod_unreg_security
使其后的安全模块可以向已经第一个注册的主模块注册和注销，但其策略实现由主模块决定：是提供某种策略来实现模块堆栈从而支持模块功能合成，还是简单的返回错误值以忽略其后的安全模块。
这些函数都提供在内核源代码文件security/security.c中
（5） 将大部分权能逻辑移植为一个可选的安全模块
Linux中已实现Posix. 1e 的权限机制的子集的支持，LSM将其独立出来作为安全模块实现，并可以和其他安全模块堆栈使用。