安全体系结构与七个设计原则

万胜 · 发表于 2022-3-26 10:36:45

安全体系结构的七个设计原则。
FLASK体系结构的主要特点。
FLASK体系结构中客体服务器OM和安全服务器的基本组成和作用。
LSM框架的特点，及其对内核的主要修改

第一章安全体系结构的七个设计原则

1.安全体系结构定义：安全体系结构描述的是一个系统如何组织成一个整体以满足既定的安全性要求
2.安全体系结构组成：1）详细描述系统中安全相关的所有方面。这包括系统可能提供的所有安全服务及保护系统自身安全的所有安全措施，描述方式可以用自然语言，也可以用形式语言。2）在一定的抽象层次上描述各个安全相关模块之间的关系。这可以用逻辑框图来表达，主要用以在抽象层次上按满足安全需求的方式来描述系统关键元素之间的关系3）提出指导设计的基本原则。根据系统设计的要求及工程设计的理论和方法，明确系统设计各方面的基本原则。4）提出开发过程的基本框架及对应于该框架体系的层次结构。描述确保系统安全需求的整个开发过程的所有方面
3. 安全体系结构作用：
安全体系结构在整个开发过程中必须扮演指导者的角色。①、要求所有开发者在开发前对安全体系结构必须达成共识; ②、在开发过程中自觉服从于安全体系结构; ③、在工程实现阶段也必须在体系结构的指导原则下进行工作。
因此：1）安全体系结构应该只是一个概要设计，而不是系统功能的描述。2）安全体系结构应该有模块化的特性。
4.七个设计原则：
(1)从系统设计之初就考虑安全性:因此在考虑系统体系结构的同时就应该考虑相应的安全体系结构。
(2)应尽量考虑未来可能面临的安全需求
(3)实现安全控制的极小化和隔离性:并不是建立的控制越多就越安全，最小开销达到最大的安全系。安全组件与其他组件隔离开来。
(4)实施极小特权：不应该让某些用户具有过高的权限。
(5)安全相关功能必须结构化：具有一个好的体系结构，安全相关的部分能够被确定，总体上能够很快对系统检查。对安全功能由清晰的易于规范的接口。
(6)使安全性能“友好” ：增加安全性不要给合法用户带来负担
(7)使安全性不依赖于保密：可以告诉用户摄像头在哪，可以告诉用户消防器在哪。
第二章FLASK体系结构

1.FLASK体系结构对策略灵活性的支持应包含以下内容：1）支持多种安全策略；2）可实现细粒度的访问控制；3）能够确保访问权限的授予与安全策略保持一致；4）能够撤回先前已授予的访问权限。

2. FLASK体系结构由客体管理器OM和安全服务器SS组成。（1）OM负责实施安全策略（2）SS负责安全策略决策。
FLASK描述了客体管理器和安全服务器之间的交互，以及对它们内部组成部分的要求。
3. 客体管理器OM基本组成
第一，为客户端提供访问决策、标记决策和多实例化决策的接口。（用户想访问某个资源，OM给用户提供相关功能、用户要创建某个新资源，OM给它打标签，赋予安全属性、多实例化的要求）
访问决策确定一个访问是否被允许。
（2）标记决策确定应该授予客体何种安全属性：
（系统的安全策略是可变的，所以主客体打的安全标签也是可变的，当系统策略变化的，系统仍然可以支持变量的类型。例如C语言中void指针强制转为int）
FLASK体系结构为解决多种需求之间的冲突提供了两个策略独立的数据类型来标识客体。①security context, 一种可变长串，它可以被任何理解安全策略的应用程序或者用户来解释。②security identifier (SID), 由FLASK定义的一个具有固定长的值，它只可以由SS解释，并由SS映射到特定的安全上下文

多实例化决策确定当前多实例化资源中哪一个成员应该被访问。：
通过多实例化某资源来按组划分终端实体，使得每个组中的实体能共享该资源的相同实例，来限制固定资源在终端实体间的共享。
例如：多级安全的Unix/Linux系统经常划分/tmp目录，为每个安全级保留独立的子目录。

第二，提供一个访问向量缓冲器AVC (Access Vector Cache), 暂时缓存访问决策结果，以提高系统效率。（例如某个请求，被允许过，下次访问，可以直接咨询AVC，提高访问决策效率）
第三，提供接收和处理安全策略变动通知的能力。：
支持策略吊销：
安全策略的改变要求在OM和SS之间进行协调以确保它们的策略表达是一致的。有效的原子性是通过系统中加入以下需求获取的：
     1）在策略改变完成后，OM的行为必须反映这个变化。如果没有后续的策略变化，不允许需要被吊销许可的受控操作执行。
     2) OM必须采用实时的方式完成策略的改变。
为满足1），OM和SS之间应该提供一种协议，分三步：
第一，SS让所有的OM注意到以前策略任何部分发生了改变
第二，每个OM更新内部状态以反映这些改变
第三，每个OM让SS注意到改变已完成
OM的实时性要求使协议提供的原子性合理。
吊销请求不能被不可信软件行为任意地延迟。
每个OM一定能够更新自己的状态，而不会受到客户的随意阻挠。
当这种实时性要求被推广到系统级策略变更时，它将牵涉到系统的另外两个组件：
微内核，为OM和SS之间提供实时的通信；
调度程序，为OM提供CPU资源。
Fluke API的两个性质简化了微内核的吊销机制：
它提供了线程状态的及时的和完全的输出
确保所有内核的操作或者是原子性的，或者是可清楚地细分为用户可视的原子性阶段。
第一条性质允许内核吊销机制访问内核的状态，包括正在运行的操作。吊销机制可以安全地等待正在运行操作的结束或者为保证及时性而重启它。
第二个性质允许将FLASK的许可检查嵌入到与他们控制的服务一样的原子性操作中，这样可避免吊销请求完成之后再出现该服务。
4. Security Server安全服务器
安全服务器需要提供安全策略决策、保持SIDs和安全上下文之间的映射、为新创建的客体提供SIDs、提供成员客体的SIDs、控制OM的AVC。此外大多数SS的执行会对载入和改变策略提供相应的功能。
除了OM中的AVC机制以外，对SS提供一个自己的缓存机制保存访问计算的结果，可以缩短它的反应时间。
1. SS的强制性:SS是一个典型的策略强制执行者。表现在：
(1)如果SS对改变策略提供了接口，它必须对主体能够访问的接口强制执行安全策略。
(2)必须限制能够获取策略信息的主体。这在一个策略中的许可请求可改变策略时显得非常重要，如:一个动态的利益冲突策略。如果策略信息的机密性很重要，OM必须负责为它缓存的策略信息提供保护。
2. SS中的安全策略管理:
被Flask安全服务器封装的安全策略是通过对它的代码和一个策略数据库的绑定来定义的。
(1)任何能够被原始策略数据库语言表达的安全策略，可以仅仅通过改变策略数据库来实现。
(2)对其它安全策略的支持需要对安全服务器内部的策略框架进行改变，可以改变代码或者完全更改安全服务器。
(3)有一点值得注意的是即使需要对安全服务器的代码进行改变，也不需要对客体管理器进行任何变动。
第三章LSM框架

第一部分：LSM的特点：
1.LSM简介：由Linus Torvalds本人带头发起。LSM为主流Linux核心提供了一个轻量级的，通用目的的访问控制框架，使得很多不同的访问控制模型可以作为可加载模块（Loadable Kernel Module）来实现。
2. Linus本人认为该框架的特点为:
（1）真正通用，使用不同的安全模型的实施仅仅是加载不同的核心模块；（2）概念上简单，最小的扩散，有效；（3）能够作为一个可选安全模块，支持现有的POSIX.1e权能逻辑。
另一方面，各种不同的Linux安全增强系统对Linux安全模块（LSM）提出的要求是：能够允许他们以可加载内核模块的形式重新实现其安全功能，并且不会在安全性方面带来明显的损失，也不会带来额外的系统开销。
第二部分LSM的5处修改（P168）
【内核关键数据结构的修改，钩函数的调用，新增安全系统调用，安全模块管理，独立capability模块】
（1）    在特定的内核数据结构中加入安全域：加载时候要赋值，卸载时候要释放，void*security
（2）    在内核代码中的管理域和实现访问控制的关键点介入对钩子函数的调用:原来的内核里面加入钩函数，LSM提供了153个钩函数。
（3）    加入一个通用的安全系统调用：可以灵活扩展——提供新的系统调用
asmlinkage long sys_security (unsigned int id, unsigned intcall, unsigned long *args).
   @ id: moduleid. Can use id to help identifywhich   module user app is talking to.
   @ call: callidentifier
   @ args: arg listfor call
实现系统调用分发，便于扩展新的系统调用
（4）    提供函数允许内核模块注册为安全模块，或者注销一个安全模块
内核初始启动时是一般系统的状态，加载的是dummy模块（支持传统的超级用户模式）
主模块管理
加载：register_security:实现security_ops和其引用的钩函数对应。该机制用于设置主模块，负责每个钩函数函数的最终决策。
卸载：unregister_security:返回初始状态。
模块堆栈管理：mod_reg_security，mod_unreg_security
使其后的安全模块可以向已经第一个注册的主模块注册和注销，但其策略实现由主模块决定：是提供某种策略来实现模块堆栈从而支持模块功能合成，还是简单的返回错误值以忽略其后的安全模块。
这些函数都提供在内核源代码文件security/security.c中
（5）    将大部分权能逻辑移植为一个可选的安全模块
Linux中已实现Posix. 1e 的权限机制的子集的支持，LSM将其独立出来作为安全模块实现，并可以和其他安全模块堆栈使用。
第四章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中。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

安全体系结构与七个设计原则

本帖子中包含更多资源