PKU-操作系统与虚拟化安全

操作系统与虚拟化安全课程小结，虽然开卷，然而紧张。。。*代表有一部分没有补全，&代表这部分内容很多，不详细，请参考PPT。

0. 操作系统概述

0.1 操作系统原理与发展史

Focus on 微内核

• 操作系统的主流结构：微内核、宏内核。

• 什么是微内核？足够小的内核 基于客户-服务器模式 实现机制和策略的分离 采用面向对象技术。 OS 基本功能-微内核，OS其他功能-用户态服务器。

• 微内核结构操作系统…

• 宏内核结构操作系统…

• 微内核操作系统的好处

• 改变操作系统功能的技术：网络计算、多核计算、可信计算、虚拟化计算、移动计算、云计算

• 操作系统基本概念：

  • 定义，任务
  • 设计目标
  • 功能：CPU, Storage, I/O, File System, User Interface
  • 主要特性：并发行，共享性，异步性
  • 引导？外部存储器 -> OS -> 主存储器
  • 过程和原理：
    • 上电（硬件电路决定），BIOS软件固化在内存，CPU直接读BIOS中的指令。
    • BIOS自检和加载引导扇区
    • 加载引导扇区
    • 加载操作系统
    • 运行操作系统

• CPU管理：

  • 中断
    • 中断或中断机制是实现多道程序设计与并发执行的基础和必要条件。如果没有中断，操作系统就无法获得系统的控制权，就不会将CPU（也作为一种资源）分派给不同的进程而实现并发执行。
    • 中断源类型：强迫性中断，自愿性中断
  • CPU调度
    • 对处理机的调度最终归结为对进程和线程的管理
    • 多道程序，并发并行
  • 进程
    • 进程是一个可并发执行的具有独立功能的程序关于某个数据集合的一次执行过程，也是操作系统进行资源分配和保护的基本单位。
    • 进程与程序的联系与区别。
    • 三个状态：Running, Ready, Blocked，还有转换。
    • PCB，进程 = 程序 + 数据 + 进程控制块，三者的定义和关系。
    • 缺点：进程时空的开销大，进程间通信的代价大，进程之间的并发性粒度较粗，不适合并行计算和分布式计算的要求，不适合客户/服务器计算的要求
  • 线程
    • 引入原因，线程含义
    • 属性拆开：独立分配资源和调度分派执行
    • 好处
    • 进程线程一对多
    • 二者比较和关系
  • 调度
    • 调度层次：低级、中级、高级
    • 调度算法目标：资源利用率、公平性、均衡性、策略强制执行
    • 算法：FCFS, SJF, 高响应比优先
    • What, Why, How

• 存储管理：

  • 功能：分配、共享、保护、扩充。
  • 存储体系结构（缓存）
  • 虚拟存储器
    • 概念
    • 基本原理
    • 缺页请求

• 设备管理

  • 特点，目的
  • 概述：存储设备，IO设备
  • 资源角度分类：独占、共享、虚设备
  • Linux分类：块、字符、网络设备
  • 目的和任务
  • 功能

• 文件管理

  • 文件、文件系统定义
  • 信息流
  • 目录、目录结构
  • 文件分类
  • 目的
  • 基本功能

0.2 操作系统设计技术

Focus on 各个子系统

• 内核导论

  • 文件子系统
  • 进程控制子系统
  • 硬件控制

• 文件内部表示

  • Inode & inode table
  • 磁盘索引节点，内存索引节点
  • 文件表
  • 用户文件描述符表(file_struct结构体)
  • 文件相关三个表的关系：用户文件描述符表、文件表、内存索引节点表
  • Fork操作系统语义
  • Linux进程相关三个表之间的关系：task_struct -> fs_struct -> inode
  • VFS与具体文件系统的关系，file_operations数据结构

• 进程结构

  • 进程的基本概念
  • 进程的数据结构
    • 进程的标识
    • 进程树和进程之间的关系
    • 进程的上下文
  • 进程表与u区、系统区表、进程区表
  • 进程状态以及转换
  • 进程的控制
  • 进程间通信
  • IPC机制的共性
  • 消息队列、共享存储区、信号量、的系统调用

• I/O子系统：

  • 基本概念
  • 接口

0.3 虚拟化技术概述

Focus on 虚拟化概念

• 数据中心现状和趋势
  • 传统数据中心的IT资源配置模式 — “烟囱式”结构
  • 缺陷
  • 资源利用率低下的原因
  • “冰山模式”—传统数据中心的成本支出结构
  • 数据中心的IT基础架构发展路径，三个阶段性步骤：整合 -> 虚拟化 -> 自动化
  • 随机应变的数据中心：非虚拟环境、虚拟环境
• 虚拟化
  • 定义
  • 常见类型：基础设施虚拟化、系统虚拟化、软件虚拟化。
  • 基础设施虚拟化：网络、存储虚拟化
  • 系统虚拟化
  • 软件虚拟化
• 虚拟化关键技术
  • 服务器虚拟化技术，云计算的核心技术
  • 技术发展
  • 体系结构
  • 实现技术的分类：全虚拟化、泛虚拟化、硬件辅助虚拟化
  • VMM分类
  • VMM实现技术：CPU虚拟化、内存虚拟化、IO虚拟化
  • CPU虚拟化：
    • 特权指令与非特权指令
    • 虚拟化系统下CPU等级划分的困难
    • 硬件CPU虚拟化
  • 内存虚拟化
    • 概念
    • 方法
  • IO虚拟化
    • 概念
    • 缺点
• 主流的虚拟化软件与虚拟化技术实践
  • VMWare: 不开源
  • Xen: 开源
  • 硬件对虚拟化的支持

0.4 系统虚拟化关键技术

• 系统虚拟化的主要用途：隔离、合并、迁移、个性化
• CPU虚拟化：
  • 概念
  • 基于额度的调度方法
  • 威胁：
    • 基于Xen Credit调度算法脆弱性的拒绝服务
    • 抗干扰虚拟机隐蔽通道－信息泄漏
  • 软件解决：客户端降权
    • 在0环以上运行 Guest OS时，敏感指令运行会出错
    • 在VMM中 处理Guest OS运行敏感指令时所产生的错误
  • CPU虚拟化挑战
  • 硬件辅助CPU虚拟化
  • Intel VT-x操作模式，VMX指令集。
  • VM Entry and VM Exit
  • 虚拟机控制结构 (VMCS)
• 内存虚拟化：机器地址、物理地址、虚拟地址。
  • 页表虚拟化
  • MMU泛虚拟化与影子页表的比较
  • 内存虚拟化优化机制: a. 按需取页与虚拟存储，两种方案。 b. 内存共享—内存页面的写时复制机制。c. 内存可写工作集（writable working sets) 的使用 d. 硬件辅助内存虚拟化
  • 硬件辅助内存虚拟化-Intel 虚拟处理器标识（VPIDs), 硬件辅助内存虚拟化- Intel 扩展页表EPT
• IO虚拟化：
  • 虚拟化方式：模拟IO设备，额外软件接口
  • Intel VT-d 硬件辅助I/O虚拟化技术
  • 基于软件的I/O虚拟化，IO设备的直接分配
  • VT-d设计，DMA虚拟化实现
    • DMA虚拟化实现，新设计的IOMMU
    • 中断重映射

1. 安全概念和标准

1.1 操作系统安全的重要性

• 安全性包括: 法律法规要求, 人身安全要求, 信息/资产保护要求
• 威胁: Software bugs(软件漏洞), Malicious users(恶意用户), Unauthorized access(未授权访问)-机制不完善, Human error(人员错误), Hardware error(硬件错误)
• 攻击:
  • 恶意代码(Malicious code)-木马，病毒，逻辑炸弹，蠕虫，天窗后门隐蔽通道等（参见教材P1-3)
  • 系统渗透(System penetration) 一 未授权访问系统资源
  • 中间人(Man in the middle)攻击者将自己置于用户和系统之间
  • 拒绝服务(Denial of service) 一 使得一个可用服务变得不可用
  • 网终嗅探(Network sniffing.) — 攻击者监听网终流量
  • 信息池露(TEMPEST) 一 从电磁辐射中抽取信息
  • 社会工程(Social engineering) — 为了达到攻击目的而欺骗人
• 安全性的两个方面：
  • 计算机安全(Computer security): 保证计算资源不被滥用或未授权使用，同时保护数据免受 意外或故意破坏、泄密或修改；
  • 通信安全(Communication security): 在计算机网络和分布式系统中的数据表示和编码信息在传 输过程中得到保护。也称网络安全。
• 数据加密不能解决所有问题，它主要解决的是数据的机密性和完整性问题，但是还有其他安全挑战。
• Windows NT安全漏洞：
  • 特洛伊木马（Trojan Horses）和病毒，依靠缺省的权力黑入。
  • NTFS文件系统中，读权限意味着同时具有读和执行的权限，文件不当执行。
• Unix/Linux安全漏洞
  • adduser/useradd设计错误，默认组名等同于用户名，可以凭借特殊用户名分入特殊用户组，从而获取权限。
  • Linux ping 缓冲区溢出漏洞：丢弃root特权失败，使得本地 用户有可能获取root权限。
• 安全性规则：安全性必须是逐层建立的，每一层的安全性应该是建立在假设底层是可信的基础之上的，在不可信层上建立安全应用是不值当的。用户空间不可信，且它可以控制内核空间（如：通过内核模块的插入权限提升 -> 内核空间也是不可信的。What we need is:

小Demo: 老鼠吃曲奇，如何保护曲奇？保护房子(No)，保护曲奇(Yes)

• 安全系统的定义：
  • 它是从一个授权状态（或安全状态）开始的
  • 它不会进入一个未授权状态（或非安全状态）
• 安全与可信的比较

Secure	Trusted
Binary	Graded
Property of presenter	Property of receiver
Asserted, based on characteristics	Judged, based on evidence
Absolute	Relative
Goal	Characteristic

Main concepts of “trusted”:

1. 执行安全策略（Enforcement of security policy）：确保所有安全相关的策略得到有效执行。
2. 充分的措施和机制（Sufficient measures and mechanisms）：采取足够的安全措施和机制来保护系统和数据。
3. 评估（Evaluation）：对安全措施和策略进行定期评估，以确保它们的有效性和适用性。

1.2 国内外技术现状

• 背景
  • 作为战略技术资源，国外对高级别（B1级以上）安全操作系统的出 口进行了严格的限制。
  • 对已经掌握的方法和关键技术也进行了严格保密，文献中很难见到 有关技术细节。
• 所有技术：
  • Multics (多重信息计算服务系统): 1965年由美国贝尔实验室和麻省理工学院的MAC项目组联合开发。旨在实现并发访问信息存储系统时的高安全性，包括受控共享、用户鉴别、用户间隔离等。虽然结果不太理想，但为安全操作系统研究迈出了重要的第一步。
  • Adept-50: 美国军方第一个实用的分时（time-sharing) 安全操作系统。以一个高水印模型(high-water-mark model)为基础， 为给定的安全问题提供了一个比较形式化的解决方案。
  • PSOS (Provably Secure Operating System): 1973-1980年间开发的层次化、基于权能的安全操作系统，使用严格的工程过程减小了安全性论证的复杂性。
  • KSOS (Kernelized Secure Operating System): 1977年由美国国防部研究计划局发起，由Ford公司承担的项目，采用形式化流分析技术，目标是高安全可信性。
  • LOCK(Logical Co-processing Kernel): 可验证安全操作系统项目是在美国政府的资助下由 国家计算安全中心于1987－1992年完成的，目标是 达到或超过TCSEC A1级安全需求的安全系统。
  • XENIX (Secure XENIX & Trusted XENIX): IBM公司于1986年开发的安全操作系统，目标是TCSEC的B2级至A1级。1989年，产品更名为Trusted XENIX，并提供了更高级别的安全特性。
  • TMach (Trusted Mach) & DTMach (Distributed Trusted Mach): 分别于1987年和1992-1993年由美国TIS公司和NSA及安全计算公司SCC的研究人员开发。TMach旨在实现B3级系统，而DTMach是基于TMach和LOCK项目的分布式系统。
  • DTOS (Distributed Trusted Operating System): 1997年完成的项目，旨在开发原型安全微内核并研究微内核操作系统的保证技术。它是DTMach之后的项目，由NSA、SCC和犹他州大学的Flux项目组合作开发。
  • TUNIS: 加拿大多伦多大学于1989年开发，重点在于改进BLP模型和UNIX内核的重新实现，使用Turing Plus语言。系统设计目标是B3至A1级，但只提供了原型系统。
  • ASOS (Army Secure Operating System): 由TRW公司于1990年完成的军用安全操作系统，分为多级安全操作系统（TCSEC A1级）和专用安全操作系统（TCSEC C2级）。主要特点包括多平台兼容、Ada语言开发、自主访问控制、BLP模型的机密性控制和Biba模型的完整性控制。
  • STOP (SCOMP Trusted Operating Program): Honeywell公司为安全通信处理器开发的操作系统，于1985年通过美国国防部TCSEC A1的评估。采用Pascal语言实现内核软件。

这些系统代表了安全操作系统领域的不同方向和发展阶段，每个系统都有其独特的安全特性和发展历程。

• 1990年以来，我国参照TCSEC B1, B2级和GB17859 第三级、第四级进行安全操作系统的研究和探讨。

• J. P. Anderson研究报告，1972年，提出

  • 引用监控器(reference monitor)
  • 引用验证机制(reference validation mechanism)
  • 安全内核(security kernel)
  • 安全建模(modeling)，即开发安全系统首先必须建立系统的安全模型，完成建模之后，再进行安全内核的设计与实现。

1.3 国内外相关标准*

• Evaluation Criteria
  • TCSEC: Trusted Computer System Evaluation Criteria
  • ITSEC: Information Technology Security Evaluation Criteria
  • FC: Federal Criteria for Information Technology Security
  • CC: Common Criteria
  • Many others

1. 彩虹系列 (Rainbow Series):
   • 以1985年美国国防部发布的《可信计算机系统评测标准（TCSEC）》为核心。
   • 对评测标准进行扩充，提供了关键的背景知识，深入解释和分析关键概念，并提出具体实现方法和措施。
   • 彩虹系列是信息系统安全事业的里程碑，建立了一套被普遍接受和使用的标准体系。
2. **TCSEC (Trusted Computer System Evaluation Criteria)**，通常称为橙皮书，是美国国防部制定的一系列用于评估计算机系统安全性的标准。TCSEC首次发布于1983年，并在1985年更新。它是彩虹系列丛书的核心，也是后续许多安全标准的基础，包括ITSEC和CC。TCSEC是评估计算机信息系统安全性的先驱，并对信息系统安全领域产生了深远影响。
   • TCSEC的主要内容包括：
     1. 评估等级：将系统安全划分为D、C1、C2、B1、B2、B3和A1七个等级，每个等级都有其特定的安全要求。这些等级按照从最低到最高的安全性进行排列。
     2. 安全功能：不同等级的系统需要实现不同的安全功能，包括但不限于用户身份验证、访问控制、审计和保证措施等。
     3. 安全保证：随着等级的提高，系统需要提供越来越高级别的安全保证，如形式化验证和设计。
     4. 实现方法和措施：TCSEC描述了如何实现特定等级的安全要求，并提供了相应的指导和措施。
   • TCSEC的评估体系建立了一个用于确保计算机系统可信度的标准框架。这些标准框架包括了对安全策略的定义、对安全机制的描述以及保障措施，旨在确保系统能够抵御外部威胁和内部滥用。TCSEC及其彩虹系列丛书的发展标志着信息系统安全事业的重要里程碑，建立了一个被普遍接受和使用的标准和体系，并且提出的基本概念、原则和方法被广泛应用于各种信息技术产品和系统的安全评估中。
3. ITSEC (Information Technology Security Evaluation Criteria):
   • 由法国、德国、荷兰和英联邦于1990年发布，欧共体于1991年发布了可操作的1.2版本。
   • ITSEC 是一套评估产品和系统安全的标准，每次评估通过功能性测试和渗透测试对IT安全属性进行详细检查。
   • 引入了保密性、完整性和可用性的概念，以及安全目标（ST）的概念。
   • 安全性要求分为“功能”和“保证”两部分，功能要求包括技术安全措施如访问控制等，保证要求如安全脆弱性分析等。
   • 分别衡量安全功能（F1-F10）与安全保证要求（E0-E6）。
4. CC (Common Criteria for IT Security Evaluation):
   • CC是在ITSEC基础上发展起来的，由六国七方在1996年共同提出的通用安全测评标准。
   • 1997年颁布了2.0版，1999年被ISO确立为国际标准ISO/IEC 15408。
   • CC提供了一组通用要求，使各种独立的安全评估结果具有可比性，以确定产品和系统的安全功能及相应保证措施的可信级别。
   • 目标读者包括用户、开发者和评估者。
   • 关键概念包括评估对象（TOE）、保护轮廓（PP）、安全目标（ST）、TOE安全策略（TSP）和TOE安全功能（TSF）。
   • CC核心内容涵盖安全功能要求和安全保证要求，其中安全保证要求定义了七个评估保证级别（EAL1~EAL7）。
5. 中国国内相关标准:
   • GB17859-1999计算机信息系统安全保护系统等级划分准则。
   • GB/T 18336.1~3-2001信息技术安全性评估准则。
   • GB/T 20272—2006操作系统安全技术要求。
   • GA/T 388-2002计算机信息系统安全等级保护操作系统技术要求。
   • GA/T 390-2002计算机信息系统安全等级保护通用技术要求。

TODO: 讨论题作业请放在这里

请阅读GB17859，分组完成以下任务之一（下次课之 前分组讲解）： –（1）可信计算基、引用监控器概念是如何定义的？ –（2）五个可信等级是什么，划分的原则是什么？ –（3）涉及的安全功能主要要求包括哪些？ –（4）区分第二级与第三级安全功能要求的异同之处？ –（5）区分第三级与第四级安全功能要求的异同之处？

1.4 安全概念和设计思想

• 访问控制思想: 由B. W. Lampson于1969年首次提出，涉及主体、客体和访问控制矩阵的概念，并抽象化访问控制问题。在一个操作系统中，每一个实体组件都必须或者 是主体，或者是客体，或者既是主体又是客体。

• 主体与客体: 在操作系统中，客体是指被动的实体（如文件或进程），而主体是指能够引起信息流动的实体（如用户或进程）

• 访问控制：

  • 访问控制是系统授予或撤销访问某些数据或执行某些操作的任何机制。通常，用户首先必须使用某种认证系统登录到系统。接下来，访问控制机制通过将用户ID与访问控制数据库进行比较，来控制用户可能或不可能进行的操作。
  • 访问控制系统包括：文件权限，例如在文件服务器上创建、读取、编辑或删除文件的权限。程序权限，例如在应用服务器上执行程序的权限。数据权限，例如在数据库中检索或更新信息的权限。

• 访问控制矩阵，描述主客体直接控制权限的关系，是一张二维表格，行列分别是主体和客体，表格中的值为主体对于客体拥有的权限。

• 通用安全需求:

  • 机密性（防止信息泄露）是指不要泄露信息(也包括数 据的存在性)或资源。加密和访问控制机制支持机密性。
  • 完整性（防止未授权修改）是指对数据或资源的可信赖程度，它通 常用于防止不当或未授权的修改。数据的完整性包括：数据的完整性和来源的完整性。访问控制支持完整性。
  • 可追究性（对数据访问和系统使用行为可追溯性）系统必须保证对数据的访问和 系统能力的使用的个人行为可追究性，并且提供审计它们的方法 。涉及标识、鉴别和审计等。
  • 可用性（信息或资源的使用能力）。是指使用所期望的信息或资源的能 力。安全相关的可用性方面是指有人蓄意造成数据的访问拒绝或使得服务不可用 。

• 安全三要素: 安全策略（Security Policy）-> 应该做什么? ，安全机制（Security Mechanism）-> 如何做? ，安全保证（Security Assurance）-> 效果如何?

安全策略

• 类型

  • 机密性策略 Confidentiality Policies -> 保密性策略没有对客体设置信任。
  • 完整性策略 Integrity Policies -> 完整性策略表明在多大程度上信任客体。

• 策略语言

  • 策略语言是描述安全策略的语言。
  • 策略语言分类：
    • 高级策略语言：使用抽象的方法来表达对实体的策略约束。
    • 低级策略语言：根据系统中程序的输入或调用选项来表达 约束。

• 安全模型

  • 一个安全模型是安全策略的清晰表述, 具有特点：是精确的、无歧义的。是简单和抽象的，易于理解。只涉及安全性质，不限制系统的功能及其实现。
  • 作用：明确安全性的定义。指导设计和实现。为安全测试提供上下文：使得可以识别对应于安全测试的抽象实体、目标的数据结构和过程。提供论证保障：论证保障就是安全系统正确实施安全策略的证明。

安全机制

• 安全机制是实施安全策略的手段，它们可以被划分为三大类别：预防、检测、恢复。通常使用的是预防机制。 检测和恢复机制通常涉及长期活动，并且是必要的，因为仅仅依靠预防是不够的。

• 引用监控器(Reference Monitor): 1972年，J.P. Anderson提出了引用监控器概念，这是一种访问控制概念，指的是一个抽象的机器，它介入并管理主体对客体的所有访问。Morri Gasser对引用监控器进行了扩展，将其定义为硬件和软件的结合体，负责强制执行系统的安全策略。

  

• 引用验证机制(Reference Validation Mechanism, 简称RVM): 是引用监控器概念的实际应用实现。它必须满足以下三个要求: a. 引用验证机制必须是防篡改的。 b. 引用验证机制必须始终参与到所有访问控制中。 c. 引用验证机制必须足够小，以便于进行测试（如有必要，可以进行彻底的测试）。

• 安全内核: 安全内核方法的根本：在一个大型操作系统中，由相对小的软件部分负责安全性，且必须满足对应RVM三个原则：

  • 完整性（Completeness): 必须做到无法绕过, it must be impossible to bypass.
  • 隔离性（Isolation): 必须是防篡改的，it must be tamperproof.
  • 可验证性（Verification): 必须能够证明其正确实施，it must be shown to be properly implemented.

• 三个基本设计原则：

  • 完整性原则：意味着所有对信息的访问必须通过内核来中介。
  • 隔离性原则：声明内核必须是防篡改的。
  • 可验证性原则：
    • 设计标准：
      • 使用最新的软件工程技术
      • 强调内核接口功能的简洁性
      • 通过排除与安全无关的功能来最小化内核的大小。
    • 确保技术：
      • 代码审查
      • 彻底测试
      • 正式的数学规范和验证

• 系统边界与安全周界(System Boundary & Security Perimeter):

  • 系统是一个包含了开发者所能控制的全部计算和通信环境的不明确实体。系统内部的一切都由系统保护，而系统外部的一切则无保护，因此，识别系统边界的关键在于准确指定系统与外部世界之间的接口。
  • 系统内部的组件分为两种类型：一种是负责维护系统安全的组件，另一种是其他所有组件。与安全相关的组件实施内部控制。区分这两种类型组件的是一个被称为安全周界的假想边界。

• 可信计算基(Trusted Computing Base, TCB): 包括了所有必须信赖的硬件和软件，以强制执行系统的安全策略。这包括：a. 访问调节的硬件与软件。b. 身份识别和认证（I&A）机制。c. 审计机制。d. 可信软件，即那些不受非可信软件强制执行规则限制的软件。

• 可信软件与不可信软件：

  • 可信软件仅指与安全相关且位于安全周界内的部分，其故障可能对系统的安全产生不利影响。可信软件首先由可信的个体根据严格的标准开发，其次已通过使用形式建模和验证等先进工程技术被证明是正确的。
  • 不可信软件则不与安全相关，位于安全周界之外：它可能是维持系统运行所需的，但它不能违反系统安全。

安全保证

• 安全功能 -> 它提供了哪些保护特性？
• 安全保证 -> 这些保护特性的可靠性如何？
• 信任(Role of Trust):
  • 分析系统的安全性需要：
    • 理解强制执行安全策略的机制。
    • 了解相关的假设和信任（任何安全策略和机制都是基于特定的假设和信任）。
  • 例如，假设有一个与安全相关的程序S，在操作系统O上进行了形式化证明。那么在安装这个程序时，需要做以下假设：
    • S的形式化验证是正确的，即其证明是无误的。
    • S的形式化证明所做的假设是正确的。
    • 程序必须被转换成可执行文件，且该可执行文件的功能与程序源代码指示的功能一致。
    • 硬件需要按照意图执行程序，例如，避免因芯片缺陷导致的运算错误。
• 安全体系结构(Security Architecture)
  • 安全体系结构描述了系统如何组建以满足安全需求。
  • 如果安全需求要求系统必须达到一个特定的保证级别以确保安全性控制的正确性，那么安全体系结构必须规定开发过程中所需的设计原则。此外，安全体系结构的指导作用将贯穿于开发过程的每一个步骤。

1.5 TCG可信计算技术介绍&

• 可信计算概念与需求：

  • 安全是指采取技术和管理的安全保护手段，保护软硬件与数据不因偶然的或恶意的原因而遭受到破坏、更改、暴露。
  • TCSEC：可信计算机系统评估标准 分为A/B/C/D四类七个等级-D,C1,C2,B1,B2,B3,A1。CC：公共准则(ISO/IEC 15408) 分为EAL1, EAL2, EAL3,EAL4,EAL5,EAL6,EAL7
  • 安全保障技术与效果
    • 攻击者进不去 -> 标识与鉴别
    • 非授权者重要信 息拿不到 -> 访问控制
    • 窃取保密信息看不懂 -> 数据加密
    • 系统和信息 改不了 -> 完整性保护
    • 可用性资源管理+安全管理 -> 系统工作瘫不成
    • 攻击行为赖不掉 -> 安全审计

• 可信计算概念与需求

  • 可信 -> 针对某个特定的目的，实体的行为与预期的行为相符，则称针对这个目的， 该实体是可信的。
  • 建立可信计算环境的需求 + 计算机安全攻击所造成的损失 + 正在变化中的计算机安全威胁。(看PPT)

• 可信计算涵义与属性

  • “可信计算”可以从几个方面来理解
    • 用户的身份认证：这是对使用者的信任
    • 平台软硬件配置的正确性：这体现了使用者对平台运行环境的信任
    • 应用程序的完整性和合法性：这体现了应用程序运行的可信
    • 平台之间的可验证性：指网络环境下平台之间的相互信任。
  • TCG制定的规范中定义了可信计算的三个属性
    • 可鉴别：计算机系统的用户可以确定与他们进行通信的对象身份。
    • 完整性：用户确保信息能被正确传输。
    • 私密性：用户相信系统能保证信息的私密性。

• 可信计算的机遇

  • 得到产业界支持的、基于标准化: • 提供一个更安全的计算环境 • 保护终端用户数据 • 提供可信的电子商务交易 • 基于硬件的信任
  • 更多的信任: • 增加用户及管理员使用因特网的信心 • 降低商业，特别是关键行业（金融、保险、政府、医疗）的风险 • 在硬件的保护下增加交易量和交易额。

• TCG

  • TCG组织介绍、工作组和一些杂七杂八：Blablabla，建议看PPT…这种不会考吧…

  • TCG的解决方案: • 将平台转变为可信计算环境 • 使平台能够证明给定的网络环境是一个受保护的环境 • 在正确的平台环境下，秘密才会被释放出来 • 将TPM作为产品中的可信构造块

  • 当前应用: • 带有TPM的PC、Server、IoT设备 • 第三方软件使用TPM提供数据保护、网络访问、标识管理、认证 • 网络产品：Radius认证服务器、病毒保护、策略管理

  • 现有标准规范介绍：安全性原则 私密性原则 可互操作性原则 数据的可移植性原则 可控性原则 易用性原则

  • 现有规范介绍: TCG体系结构规范, TPM主规范, TSS规范, PC客户平台规范, 服务器规范, 移动电话使用场景规范, 基础设施规范, 可信网络连接规范

  • 核心功能介绍:

    • TCG技术的核心内容就是为计算平台提供了一整套基于TPM及平台中TBB（平台可信构造块）的信任建立及可信性证实方法和机制
    • CRTM（度量的核心信任根）: • 在最初设计可信平台架构时，TCG考虑到平台改造的成本和风险，并没有将CRTM集成到TPM内部，而是通过改造主板上的 Boot ROM 来实现的。 • 在启动的最初阶段，最先执行的一部分指令就是CRTM，它负责对紧随其后执行的 其他指令进行完整性度量，CRTM是可信度量根。 • 根据信任根的定义，CRTM必须是平台上的一个受保护的部件，它必须总是按照预期的方式运作，从而能够被无条件信任。
    • 可信平台模块TPM: • 是一个拥有受保护的独立执行能力（密码运算部件)和小容量存储能力的硬件芯片。 • TPM是可信平台的核心，配合CRTM就能够实现完整性的度量和报告。 • 在可信体系的三个信任根中，TPM实现的是可信报告根RTR和可信存储根RTS的功能。

  • TPM至少需要具备四个主要功能: 对称/非对称加密、安全存储、完整性度量、签名认证。

    • 数据的非对称加密和签名认证，是通过RSA算法来实现的
    • 完整性度量则是通过高效的SHA-1散列算法来完成的
    • 对称加密可以使用任意算法，既可以使用专用协处理器，也可以使用软件来完成。

  • TPM结构：

    

    • 受保护的功能：是一组命令，只有它们才能访问被屏蔽的位置
    • 被隔离的位置：是内存，寄存器等，满足：a. 在这些位置上操作敏感数据是安全的。b. 访问数据的位置只能是受保护的功能。

• TPM的核心功能介绍

  • PCR平台配置寄存器：作用、允许的操作，密码哈希的性质。

  • 完整性度量、存储、报告机制：目的，度量方式，存储值的存储，完整性报告。

  • 信任链产生：在可信体系中，信任链以可信根（TPM）为起点而建立，在此基础上再将信任关系逐级传递到系统的各个模块，从而建立整个系统的信任关系。所以信任根 必须是一个能够被信任的组件，通常在一个可信平台中有三个可信根：

  • 可信报告根（Root of Trust for Reporting，RTR）：提供密码机制对TPM的状态及信息进行数字签名

  • 可信存储根（Root of Trust for Storage，RTS）：提供密码机制保护保存在TPM之外的信息(数据和密钥)

  • 可信度量根（Root of Trust for Measurement，RTM）：由平台提供的对平台的状态进行度量的机制

  • 信任链产生流程：

    

    信任链扩展流程所加载的组件顺序

  • 完整性报告

  • 远程报告：可信平台使用AIK对当前平台的PCR值 进行签名，报告给远程挑战者，以证明 其平台状态的可信性。 这一过程使用挑战-应答协议完成。

  • 本地报告：借助TPM本身提供的Seal操作（将数据或密钥与一个或一组指定的PCR值绑定，只有当这个或这组PCR值符合特定的指定值时，这些数据和密钥才能够被释放出来）来完成本地的安全报告。

    当挑战者要判断本地机器是否被攻陷，意味着本机有可能是不可信的。那么本机的 验证会被攻击者篡改,挑战者会受到欺骗。

  • 远程证实: 远程证实协议 -> 远程证实时，一个平台（挑战方）向另个平台（证实方）发送一个挑战证实的消息和一个随机数，要求获得一个或多个PCR值，以便对证实者的平台状态进行验证。

  • AIK证书的合法性 – EK 和 AIK：背书密钥 EK（Endorsement Key），身份认证密钥 AIKs（Attestation Identity Keys）。Privacy CA、AIK证书的合法性等。

  • 数据保护：可信平台要可信，必须真实的报告系统的状态，同时不能暴露密钥，也要尽量不能暴露自己的身份。数据安全保护是可信平台的核心功能之一：通过密钥对数据采用特定的保护方式：

    • 用于数据安全保护的密钥分为对称密钥和非对称密钥
    • 被保护的数据可以是任何数据
    • 数据安全保护方式包括数据加解密、数据封装等方式。

  • 受保护的存储结构：存储根密钥(Storage Root Key, SRK) a. 每个可信计算平台只对应一个惟一的SRK,且只保存在TPM中。 b. 在TPM所有者获得TPM所有权时，在TPM中生成SRK。 c. 以SRK为根，可以建立受保存的树状存储结构。

  • 绑定（BINDING）VS 封装（SEAL）

  • 密钥管理: 密钥与数据，存储密钥与签名密钥，密钥是否可迁移、密钥的使用。

• 可信平台软件架构: 服务提供者接口, 核心软件接口, TPM设备驱动程序接口。

2. 安全标准

2.1 硬件安全机制

Focus on Security in Hardware and OS.

• 操作系统的安全性表现: • 物理上分离：要求进程使用不同的物理实体 • 时间上分离：具有不同安全要求进程在不同时间运行 • 逻辑上分离：要求进程不能访问其允许范围外的实体 • 密码上分离：要求进程隐蔽数据及计算

• 操作系统安全的主要目标: 依据系统安全策略对用户的操作进行访问控制， 防止用户对计算机资源的非法访问(窃取、篡改 和破坏), 标识系统中的用户和进行身份鉴别, 监督系统运行时的安全性, 保证系统自身的安全性和完整性。

• 必要的安全机制: • 硬件安全机制 • 访问控制机制 – 自主访问控制、安全标记与强制访问控制、客体重用 • 可追究机制 – 标识与鉴别、可信路径、安全审计 • 连续保护机制 – 系统完整性、隐蔽通道分析、最小特权管理、可信恢复

• 硬件安全机制

  • 为什么需要硬件安全性: • 认为硬件安全特性在执行时更为可靠和正确。（不会被错误的软件损坏） • 把安全特性设置在硬件中可以形成一个更为简洁的体系结构。 • 硬件允许的工作性能（运行速度）高于软件。

  • 硬件安全目标: • 保证自身的可靠性、同时为系统提供基本安全机制，包括：存储保护, 运行保护, I/O保护

  • 存储保护

    • 存储保护的目标 • 单用户（内存一次运行一个进程）系统中 – 应该防止用户程序对操作系统的影响。 • 多道程序运行的系统中 – 需要对进程的存储区域实行互相隔离。

    • 存储器管理机制

      • 虚地址空间 – 存储进程的程序与数据的专用地址空间 – 由硬件实现虚 -实地址转换 /映射
      • 请求式页面调度 – 操作系统建立一个作用于整个进程虚拟存储器的页面描述表, 并在描述符中设置一个”ON DISK”标志,以指示那些页面不在 物理存储器中, 此时要求进行中断页处理 (整个进程用一个页表 )
      • 分段虚拟存储 – 典型二段方案：分为用户空间与系统空间 – 可变长分段与请求页面调度结合 (每个进程的段数不同,每个段 都有一个可变长的页面描述表 )

    • 存储器管理的访问控制

      • 策略：当系统的地址空间分为系统段与用户段时，应禁止在用户模式下运行的非特权进程向系统段进行写操作，而当在系统模式下运行时，则允许进程对所有的虚存空间进行读、写操作

      • 具体机制：物理页附加密钥的方法，基于描述符的地址解释机制

    • 物理页附加密钥的方法：• 每个物理页号都被标以一个称为密钥的秘密信息；系统只允许拥有该密钥的进程访问该物理页，同时利用一些访问控制信息指明该页是可读的还是可写的 。 • 每个进程相应地分配一个密钥，该密钥由操作系统装入进程的状态字中。 • 每次执行进程访问内存的操作时，由硬件对该密钥进行检验， 只有当进程的密钥与内存物理页的密钥相匹配，并且相应的访问控制信息与该物理页的读写模式相匹配时，才允许该程访问该页内存，否则禁止访问。 • 缺点：进程挂起前后物理页面不同和共享页面会带来开销。

    • 基于描述符的地址解释机制：• 每个进程都有一个“私有的”地址描述符，进程对系统内存某页或某段的访问模式都在该描述符中说明。可以有两类访问模式集，一类用于在用户状态下运行的进程，一类用于在系统模 式下运行的进程。 • W，R，E各占一比特，它们用来指明是否允许进程对内存的某 页或某段进行写、读和运行的访问操作。 • 由于地址解释期间，地址描述符同时也被系统调用检验，所以这种基于描述符的内存访问控制方法，在进程转换、运行模式 （系统模式与用户模式）转换以及进程调出 /调入内存等过程中， 不需要或仅需要很少的额外开销。

      

• 运行保护

  • 背景知识

    • 一种计算机硬件要运行Unix/Linux系统，至少需要提 供两种运行模式：高优先级的内核模式和低优先级的 用户模式。实际上许多计算机都有两种以上的执行模 式。如：intel 80x86体系结构就有四层执行特权。
    • 采取不同的执行模式是为了保护。由于用户进程在较低的特权级上运行，它们将不能意外或故意的破坏其 它进程或内核；程序造成的破坏会被局部化而不影响 系统中其它活动或者进程。当用户进程需要完成特权模式下才能完成的某些功能时，必须严格按照系统调用提供的接口才能进入特权模式运行受限的功能。

  • UNIX/Linux系统层次结构

    • 一个Unix/Linux系统分为三个层次：用户、核心以及硬件。 其中系统调用是用户程序与核心间的边界，通过系统调 用进程可由用户模式转入内核模式，在内核下完成一定 的服务请求后再返回用户模式。

    

  • 基于保护环的等级域机制

    • 执行域 – 涉及内容为：执行方式、状态以及范围。 – 域是分层的。
    • 保护环： – 分层图的图形像一组同心的环。 – 环的编号越小，特权越高。
    • 安全概念： – 保护每一环免遭其他环的影响，并允许每层环有效地控制该环及更低特权环上的应用程序。

  • 进程隔离机制

    • 给定一个进程，它可以在任意时刻在任何一个环内运行，在运行期间还可以从一个环转移到另一个环。
    • 当一个进程在某个环内运行时，进程隔离机制将保护该进程免遭在同一环内同时运行的其它进程破坏。

  • 多域结构的保护机制

    • 依据： – 如果环 n对某一段具有一个给定的访问模式，那么 所有0—n-1的环都具有这种访问模式。
    • 硬件保护机制 – 对于每种访问模式，仅需要在该描述符中指出具有该访问模式的最大环号，而不用为每个环都保存相应的访问模式信息。 – 对于一个给定的内存段，仅需 3个区域（Ｒ，Ｗ， Ｅ三种访问模式），在这 3个区域中只要保存具有该访问模式的最大环号即可。

  • Ring bracket，环界:

    • 我们称R1，R2，R3环号为环界，分别表示对该段可以进行写W、读R、运行 E操作的环界，而且满足： R1≤R2≤R3。例如：在某个段描述符中，环界集（4， 5，7）表示0环到4环可对该段进行写 操作；0环到5环对该段可进行读操作； 0环到7环可运行该段内的代码。
    • 如果某环内的某 一进程对内存某段具有写操作的特权， 那就不必限制其对该段的读与运行操作特权。如果进程对某段具有读操作的特权，那当然允许其运行该段的内容。
    • 环界方法的安全性：不允许低特权环内编写（或者修改）的程序在 高特权环内运行。对于一个给定的段，为每个进程分配一个相应的环 界集，不同的进程对该段的环界可能是不同的。存在的问题：这种方法只能隐含，但不能明确限定同一环内两个进程对共享段设立不同的访问模式。
    • 解决方法：将段的环界集定义为系统属性，仅当一个进程在环界集限定的环内运行且相应的访问模式位是 ON，那么才允许该进程对该段进行相应的访问操作。在同一环内运行的两个进程共享某个段，且欲使一个进程只 对该段进行读访问，而另一个进程仅对该段进行写访问时，只要按 需设置两个进程相应的访问模式信息即可，环界集相同。

• I/O保护

  • 从访问控制角度看，一个进程发出的I/O指令主要涉及的部分。
  • I/O硬件保护机制。

2.2 自主访问控制机制*

Focus on DAC

• 计算机系统安全机制的主要目的是访问控制，自主访问控制机制(DAC, Discretionary Access Control): 授权：确定哪些主体有权访问哪些客体，确定访问权限，实施访问权限。
• DAC – 概念：文件的拥有者可以按照自己的意愿精确指定 系统中的其他用户对其文件的访问权。定义！
• “自主”的体现
• DAC分类：基于行的访问控制矩阵信息：连接可访问客体到指定用户。基于列的访问控制矩阵信息：连接用户列表到指定的客体。
  • 基于行的自主存取控制机制：在每个主体上都附加一 个该主体可访问的客体的明细表，根据表中信息的不同可分成三种形式: 能力表、前缀表和口令。
  • 基于列的自主存取控制机制：在每个客体上都附加一个主体明细表，表 示存取控制矩阵。表中的每一项都包括主体的身份和主体对该客体的访问权限。

TODO: 讨论题作业请放在这里

【Q1】：你了解Linux内核“主体”的数据结构吗?其中uid、euid、 suid、fsuid各自的含义和用途是什么？与标识和鉴别机制的关系

【Q2】：你了解Linux内核“客体”(如文件、目录、特殊文件、设 备、IPC客体-消息队列+共享内存+信号量、信号等)的数据结构吗? 如果要为这些客体打安全标签（如安全级），应该如何添加？

【Q3】：Linux的“块设备”与“字符设备”区别是什么，相关的数 据结构如何？举例说明。

【Q4】: 你了解Linux2.6系统中与DAC相关的命令吗？如熟悉chmod, chown, setfacl, chfacl等命令的使用吗?

【Q5】：你能在Linux2.6以上内核中找出客体（如文件/目录）相关 的DAC数据结构吗（传统9Bit模式、ACL模式）？

【Q6】: 你了解Linux的SETUID机制吗？chmod命令中的特殊权限位 的S_ISUID, S_ISGID,S_ISVTX(STICKY位）是什么含义？

2.3 强制访问控制机制

MAC, Mandatory Access Control. BLP，不可上读，不可下写。

• 特洛伊木马（Trojan horses）威胁

• DAC & Trojan Horse: DAC hold不住，在DAC控制下并没有办法防止木马通过共享客 体(shared objects)-比如文件、消息和共享内存等，把消 息从一个进程传给另一个进程。

• 引入了不可绕过的（直接或间接地）访问限制。

• MAC & Trojan horses

  • MAC可以阻止一些Trojan horses攻击，主要体现在：
    • 为每个主体(subjects)和客体(objects)赋予安全属性 (security attributes),这些属性不像自主访问控制属性那样可以随意改变。
    • 系统通过比较主体和客体的安全属性来决定该主体能 否以期望的方式访问该客体。反之，如果系统判定拥有某一安全属性的主体不能访问某个客体，那么任何人（包括客体的拥有者）也不能使它访问该客体。从这种意义上讲，是“强制”的。
    • 以某个用户身份运行的进程不能改变该用户本身及该用户所拥有客体的安全属性，所以简单地通过允许其他用 户来访问一个文件不会泄露文件的内容。
    • 可以阻止进程创建共享文件，避免利用这些共享文件将敏感信息传递给另一个进程。

• 多级安全思想

  • 多级安全的思想起源：多级安全系统的主要目标是实施强制机密性安全策略,确 保信息不会被无意泄露。
  • 多级安全与军事安全策略，保密级别。
  • 支配关系，安全级的表示形式通常为：一个保密级别后随一个范畴集（可包含一个或多个范畴）。
  • 两个安全级之间存在的支配关系，两个安全级A和B之间的支配关系。包含多种。

• 多级安全规则与BLP模型

  • Simple Security Property，即：简单安全属性

  • Property or confinement property，即：属性

  • BLP的不可上读(No Read Up, NRU)和不可下写 (No Write Down, NWD)：

    • 这个原则阻止较低安全级别的主体（如用户或进程）读取较高安全级别的数据。其目的是防止敏感信息泄露给未经授权的用户。

      例子: 假设有三个安全级别：公开、机密和绝密。根据BLP模型，一个只有机密级别访问权限的用户不能读取绝密级别的数据。这意味着，如果一份文件被标记为绝密，那么那些只有机密或公开级别访问权限的用户就无法读取这份文件。

    • 这个原则阻止较高安全级别的主体写入较低安全级别的对象。这样做是为了防止敏感信息通过较低安全级别的数据流向下泄露。

      例子: 继续上面的例子，一个有绝密级别访问权限的用户不能将信息写入机密或公开级别的文件中。例如，如果一个用户正在处理绝密文件，他们不能将这些信息复制或移动到只有机密或公开级别的文件中，因为这样会使得较低级别的用户能够访问到本应更高级别保护的数据。

• 强制访问控制(MAC)机制举例

  • 安全级的标识和赋值
    • 安全级的标识与安全级数据库
    • 主体的安全级
    • 客体的安全级
    • 设备的安全级
  • MAC规则的具体实施
    • 实施的强制存取控制规则
    • 客体为文件、特殊文件、目录时。客体为进程时。客体为消息队列、信号量集合、共享存储区、管道时。
  • 如何防止Trojan horses
    • 场景1：在多级安全系统中，*–特性能阻止正在机密 安全级上运行的进程中的特洛伊木马把机密信息写入 一个公开的文件里。
    • 场景2: 一个公司对系统中自己拥有的信息指定一个强制存取范畴c，只有该公司的雇员才可能进入这个范畴c。如果它的一个雇员使用了特洛伊木马，他不可能将该公司的信息传递到c范畴以外的地方去，但在范畴c内部，信息可以在各个用户之间自由传递。

2.4 客体重用机制

• 客体重用
  • 定义：包含一个或多个客体的存储介质(例如，页面，磁盘扇区， 磁带)的主体的重新分配。
  • 残留数据又称残留信息：是指数据在被以某种形式擦除后所残留的物理表现。
• 标准要求: TCSEC（C2-A1)和GB17859(第二级第五级）的要求, CC和GB/T18336—2001(EAL 2EAL 7)。
• 硬盘、软盘、可擦写光盘的物理盘块空间
• 内存页面：“内存物理页面”和“盘上物理页面”
• 高速缓存：Linux内核在运行中常常会需要使用一些页高速缓存区，由于这些页高速缓存空间的释放和再分配，也可能会泄露其以前曾经被存放的信息。

2.5 标识与鉴别

• 可追踪机制（ACCOUNTABLE MECHANISMS）
• 之一：标识与鉴别（Identification & Authentication）
  • 基本概念：
    • 标识
    • 鉴别
  • 标识机制：
    • uid/gid
    • 主体/进程
    • FreeBSD
    • chown
  • 与鉴别有关的认证机制
    • TCB（可信计算基）要做很多工作。
• 几个技术要点：• 对口令内部存储的访问控制和加密处理 • 口令从终端到认证机传输过程中的保护 • 登陆尝试次数的限制 • 用户安全属性的检查，比如用户进程的安全 级、计算特权集、审计屏蔽码等。 • 审计处理，对口令的使用和更改进行审计； 及时通知系统管理员、通知用户等。
• 口令质量测试

2.6 可信路径机制

• 可追踪机制(ACCOUNTABLE MECHANISMS)
• 之二：可信路径(Trusted Path)
  • 用户必须确定是与真实的安全 内核通信
  • 一种用于保障用户和真实的内核通信的机制 就 是可信路径（或可信通路）
• Requirements in TCSEC
• Approaches for trusted path
  • 方法一：给每个用户两台终端，一台做通常的工作，一台用作与内核的硬连接。缺点：这种办法虽然十分简 单，但太昂贵了。
  • 方法二：对用户建立可信路径的一种现实方法是使用通用终端，通过发信号给核心。这个信号是不可信软件不能拦截、覆盖或伪造的。 一般称这个信号为“安全注意键”, Secure Attention Key 。 – 缺点：目前大多数终端十分智能，内核要使该机制不被特洛伊木马欺骗十分困难。
  • 安全注意键（SAK）机制的实现方法，激活方式等

2.7 安全审计机制

• 可追踪机制(ACCOUNTABLE MECHANISMS)
• 之三：安全审计(Security Audit)
  • 概念、目的、意义
  • Audit Assurance，为了确保审计员能够获得真实的和有价值的信 息，以作出正确的判断和及时的决策。
  • Audit Events，审计事件，是系统审计用户操作的最基本单位。
  • What events to be audited? 审计事件可分为主体审计事件和客体审计事件两 大类，主体，客体。
  • 审计事件标准
  • 主体审计事件
  • 客体审计事件
  • 事件筛选机制
  • 审计保护
  • 演示实例
  • An Example for Audit：审计点、审计过程、审计方法、审计必要机制。

2.8 最小特权管理

把权限拆细，最小特权原则！

• 之一：最小特权管理（Least Privilege Management）
  • What is the Privilege in an OS
  • 操作系统中超越DAC和MAC检查的特权
  • Basic Idea
    • 最小特权管理的思想是系统不应给用户超过执 行任务所需特权以外的特权
  • Problems in Privilege Management
  • Examples to enforce Privilege Management
  • 进程和程序文件的权能状态定义，权能遗传算法。
  • 用户初始进程的特权状态：由于用户通过会话（如：login）成为系统的主体进程，所以要在此过程中根据用户属性 (比如: 角色 )为初始的主体设置恰当的权能状态。

2.9 隐蔽通道分析与标识&

• 之二：隐蔽通道分析与标识(Covert Channel Analysis and Identification)
  • 定义：如果一个通信信道既不是设计用于通信的，也不是有意用于传递信息的，则称该通信信道是隐蔽的。
  • 在实施了强制访问控制的多级安全操作系统中，特洛伊木马只有利用隐蔽 通道才能将信息传送给低安全级进程 (木马主人）。
  • 隐蔽通道与完整性策略有关
    • 隐蔽通道的概念除了与保护信息流的安全策略有关之外，与系统的完整性策略也有关系。
      • 在实现强制安全策略（比如BLP安全策略）的系统中，隐蔽通道分析要确保能找出所有从特定安全级到低安全级或者不可比安全级的非法泄密路径。
      • 在实现强制完整性策略（比如Biba）的系统中，隐蔽通道分析要确保能找出所有从特定完整级到低完整级，或者不可比完整级的非法泄密路径。
  • 隐蔽通道分类
    • 隐蔽存储通道Storage Channel
    • 隐蔽定时通道Timing Channel
  • 噪音通道和无噪通道：无噪通道指的是发送者发送的信号与接收者接收的信号百分之百相同。
  • 无害通道与有害通道。
  • 国内外安全产品评估标准对隐蔽通道分析的要求：TCSEC (橘皮书)，我国的GB17859。
  • 国内外安全产品评估标准 对隐蔽通道分析的要求。
  • 隐蔽通道分析的基本工作流程。
  • 隐蔽存储通道的判别标准、隐蔽定时通道的判别标准。
• Identification of Covert Channels
  • 隐蔽通道分析的层次性
  • 橘皮书建议采用的分析资源
  • 源代码级分析的优点
  • 隐蔽通道的经典标识方法评价
  • 主要方法
    • Shared Resource Matrix: 优点：是目前唯一一种可以分析DTLS的方法。缺点：分析代码非常困难。（闭包！大题！）
  • 传递闭包
  • SRM方法分析
  • Covert Flow Tree & Covert Flow Graph
  • 结合语义分析的Tsai信息流分析
  • Formal method by Tsai, Tsai方法的主要缺点
• 隐蔽通道的带宽计算技术
  • 影响带宽计算的因素
  • 国外主要带宽计算技术
• 隐蔽通道的处理技术
  • 常用处理技术
  • 隐蔽通道处理技术选择因素
  • 隐蔽通道的处理技术实例
  • 隐蔽通道场景实例分析
    • 已标识隐蔽存储通道场景-1: 进程标识符信道
    • 已标识隐蔽存储通道场景 2: 最近访问时间信道

2.A 系统完整性保护

• 之三：系统完整性保护(System Integrity)
  • 完整性要求: 系统完整性（System Integrity）通常使用完整性敏感标 记来确信信息在传送中未受损。完整性保护要求包括三种类型： a,存储数据的完整性；b,传输数据的完整性；c,处理数据的完整 性。
  • 存储数据的完整性：存储数据的完整性检测，存储数据的完整性检测和恢复。
  • 传输数据的完整性：数据交换完整性检测，源数据交换恢复，目的数据交换恢复
  • 处理数据的完整性：基本回退，高级回退

2.B 可信恢复机制

• 之四：可信恢复机制(Trusted Recovery)
  • 可信恢复
    • TCB提供的过程和机制
    • 不减弱保护的情况下启动TCB
  • 可信恢复要求
    • 手动恢复
    • 自动恢复
    • 无过分丢失的自动恢复
    • 功能恢复

3. 安全模型

3.1 安全模型开发方法

• 安全策略vs.安全模型(Security Policy vs. Security Model)

  • What properties do the security policy really care about? 机密性、完整性、可用性

  • Security Policy and Security Mechanism: 安全机制是实施安全策略的某些部分的实体（entity) 或规程(procedure)。

  • Why need security model? 安全策略通常是隐含定义而不是明确定义的，安全模型是安全策略的清晰表述。

• Objectives of Developing A Formal Security Model

• Basic Demands for Developing A Formal Security Model

• State-Machine and Development of Security Models

• What is State-Machine? -> 状态变量表示机器的状态，转换函数或者操作规则用以描述状态变量的变化过程。

• Why State-Machine is suite for the Description of Security Models?

• How to develop a state-machine security model?

  1. 定义安全相关的状态变量。
  2. 定义安全状态的条件，这个定义是一个不变式， 它表达了在状态转换期间状态变量的数值所必须始终保持的关系。
  3. 定义状态转换函数。这些函数描述了状态变量可能发生 的变化，也称为操作规则，因为它们的意图是限制系统可能 产生的变化的类型。
  4. 检验函数是否维持了安全状态。要求：如果系统在运行 之前处于安全状态，那么系统在运行之后仍将保持在安全状 态。
  5. 定义初始状态，选择每个状态变量的值。
  6. 依据安全状态的定义，证明初始状态安全。

• How to prove the security of a state-machine security model?

  • 用严格的数学推导来证明系统从一个安全状态 出发，并且无论调用哪个函数系统都将保持在安全状态。
  • 证明初始状态是安全的，证明所有的函数都是安全状态。

3.2 BLP机密性安全模型

• 典型安全模型介绍(Typical Security Models)
• 经典BLP模型
  • 简介
  • BLP模型形式化地定义了系统状态及状态转换间的转换规则， 并制定了一组约束系统状态间转换规则的安全公理。
  • 模型的安全策略：自主安全策略，强制安全策略。
• 系统状态表示：描述状态机所有的状态，描述状态之间的转换，安全公理。
• 模型的几个重要定理。BLP模型为了证明系统为安全状态及转换规则保持安全状态，证明了10个重要的定理。
• BLP模型的不足，TMach对BLP的改进，Fluke Microkernel的改进，RSBAC的改进。

3.3 BIBA完整性安全模型

• Integrity Models
  • 完整性概念比机密性概念更模糊，更依赖于上下文。完整性威胁可能是意外的(accidental)或恶意的(malicious)。
  • Commercial Concerns
    • 完整性比机密性显得更加重要。
  • Principles of Operation: 三个操作原则，通常，商用安全性控制是自主的、过程的和分散的。 信息的分类也是一个很大的问题。
• Biba Integrity Model
  • 它基本是BLP模型的对偶，不同 的只是它对系统中的每个主体和客体均分配一 个完整性级别（integrity level）。
  • Information transfer path: 对一个客体的不可靠信息流破坏或毁坏了 该客体的完整性。这个不可靠的信息可能来自一个更低 完整性级别的主体或者一个更低完整性级别的客体。三种访问模式。
• Low-Water-Mark Policy on Subjects
  • 一些策略
  • Problems of LWM: 主体在对某些持有较低或不相容的完整级别的客体 执行“observe”操作后，会降低自身的完整级别，有可能减少主体可存取的客体集，使某些原来对主体说来是可以存取的客体在执行“observe”操作后 变成不可存取的
  • Other LWM Policies
• Ring Policy
  • 一些策略
  • Problems of Ring Policy：由于“observe”存取是非受限的，仍 可能发生不恰当的“modify”操作。为了避免这种情况，主体在使用来自低完整 级别客体的数据时要十分小心。
• Strict Integrity Policy
  • No Read-Down
  • No Write-Up
  • 严格完整策略防止信息从低完整性级别客体向 更高或不可比完整性级别客体传递，保证信息 流仅是“observe”和“modify” 的结果。
• Biba vs. BLP
  • 具有简单性。
  • Biba和BLP模型相结合的可能性。
• Biba模型的不足
  • 完整标签的确定很困难
  • 在有效保护数据一致性方面不完备
  • 不同性质的范畴在同时满足机密性和完整性目标方面难以配合使用

3.4 Chinese Wall混合安全模型&

• Chinese Wall Model

  • 概述
  • Organization
  • Definitions
  • Temporal Element
  • CW-Simple Security Condition
  • Sanitization
  • Writing
  • CW-*-Property
  • Compare to Bell-LaPadul

• 根据中国墙模型思想，假定公司A、公司B同属于一个利益冲突类P；公司X、公司Y同属于另一个利益冲突类Q，试 问： （1）假定用户Alice读取过公司A的数据和公司X的数据， 用户Bob读取过公司A的数据和公司Y的数据，那么接下来， 用户Alice能否写公司A的数据？为什么？请说明理由。 （2） 假定用户Alice读取过公司A的数据，以及公司X已经清洗过(sanitized)的数据，用户Bob读取过公司A的数据和公司Y的数据，那么接下来，用户Alice能否读取公司Y的数据？ 为什么？请说明理由。

根据中国墙模型的安全策略，我们可以对您的问题进行分析。中国墙模型是一种动态的访问控制策略，用于防止冲突利益和信息流的不当传递。它通常应用于金融、法律和信息服务行业。

在中国墙模型中，数据被分为不同的利益冲突类（Conflict of Interest Class）。如果一个用户访问了某一利益冲突类中的信息，那么他就不能访问其他利益冲突类中的信息。这是为了避免信息交叉导致的潜在冲突。

针对您的问题：

1. 关于Alice写公司A的数据：
   • Alice已经读取了公司A（属于利益冲突类P）和公司X（属于利益冲突类Q）的数据。
   • 根据中国墙模型，Alice可以继续访问她已经访问过的利益冲突类（即类P和类Q）中的数据。
   • 因此，Alice能够写公司A的数据，因为公司A属于她已经访问过的类P。
2. 关于Alice读取公司Y的数据：
   • Alice读取了公司A的数据（属于类P）和公司X经过清洗的数据。
   • 清洗过的数据通常意味着去除了可能引起利益冲突的敏感信息。
   • 如果公司X清洗过的数据不再被视为属于冲突利益类Q的一部分，那么Alice访问这些数据不会违反中国墙模型的规定。
   • 在这种情况下，Alice理论上可以访问公司Y的数据，因为她没有直接从属于类Q的源数据中获取信息。

3.5.1 基于属性访问控制技术研究&

• 访问控制是公认的确保数据安全共享的重要手段之一，访问控制技术根据预先设定的访问控制策略，保障资源只能被合法用户执行合法操作，防止了信息的非授权访问。
• 基于属性访问控制定义：基于属性的访问控制（Attribute Based Access Control， ABAC）：一种访问控制方法，主体对客体执行操作的请求被授 予或拒绝是基于主体所分配的属性，客体所分配的属性，环境 条件以及一组根据这些属性和条件来规定的策略。
• 基于属性访问控制定义，基于属性访问控制定义。
• 优点
• 属性访问控制研究点
• ABAC系统分为两个阶段：准备阶段和执行阶段
  • 准备阶段：主要负责收集构建访问控制系统所需的属性集合以及对访 问控制策略进行描述。
  • 执行阶段：主要负责对访问请求的响应及对访问策略的更新。

实体属性发现是ABAC研究中的基础，自动化的策略挖掘方法是需要解决的重要问题。

自动化的策略挖掘方法是需要解决的重要问题

设计复杂度较低且具有丰富表达能力的访问控制描述语言才能保证ABAC系统高效准确运行

• 基于属性访问控制研究

  • 通过以上ABAC研究点的阐述，ABAC研究主要分为ABAC模 型，策略以及属性三类
  • 纯ABAC模型
  • ABAC的混合模型
  • ABAC通用模型研究
  • ABAC特定领域模型研究
  • ABAC混合模型研究

• 基于属性访问策略研究

  • ABAC策略描述语言研究
  • ABAC策略挖掘研究
  • ABAC策融合冲突研究
  • ABAC属性发现研究
  • ABAC属性安全研究

3.5.2 RBAC中立安全模型&

• Role-Based Access Control, RBAC

  • RBAC概述

  • RBAC的优点

  • 基本概念及原理

  • 模型的基本性质

• Some issues in RBAC

3.6 DTE中立安全模型&

• Domain and Type Enforcement, DTE
  • TE/DTE 概述
  • DTE策略描述
  • DTE Implementation
  • DTE 的特点

4. 安全体系结构

4.1 安全体系结构概述

• 安全体系结构的含义及类型
  • 体系结构的主要任务：建立一个计算机系统往往需要满足多种要求，比如：安 全性要求、性能要求、可扩展性要求、容量要求、使用 方便性要求和成本要求等。全局性地折衷考虑，这就是体系结构要完成的主要任务。
  • 安全体系结构的定义：安全体系结构描述的是一个系统如何组织 成一个整体以满足既定的安全性要求。
  • 安全体系结构组成。
  • 安全体系结构作用。
  • Multiple Architectural Views
    • Abstract View，抽象体系
    • Generic View，通用体系
    • Logical View，逻辑体系
    • Specific View，特殊体系
• 安全体系结构的设计原则：七个基本设计原则
  • Consider Security from the Start
  • Anticipate Future Security Requirements
  • Minimize and Isolate Security Controls
  • Enforce Least Privilege
  • Structure the Security-relevant Functions
  • Make Security Friendly
  • Do not Depend on Secrecy for Security

4.2 GFAC与FLASK安全体系结构

• 广义存取控制框架(GFAC，General Framework for Access Control)
  • To Support Multiple Policies
  • GFAC概述
  • GFAC定义的三个概念: 权威(Authorities), 安全属性(Attributes), 规则(Rules)
  • GFAC基本结构: AEF(Access control Enforcement Facility), ADF(Access control Decision Facility)
• GFAC分析
  • 优缺点
• FLASK, FLux Advanced Security Kernel
  • FLASK安全体系结构概述
  • FLASK Architecture
  • FLASK体系结构基本组成
• Object Manager(客体管理器)
  • 客体管理器OM基本组成
  • Object Labeling客体标记决策
  • Requesting and Caching Security Decisions 请求和缓存安全决策
  • Polyinstantiation Support 支持多实例化
  • Revocation Support Mechanisms 支持吊销机制
  • A revocation of microkernel permissions
  • Fluke API的两个性质
• Security Server(安全服务器)
  • SS基本功能
  • SS的强制性
  • SS中的安全策略管理

4.3 LSM安全框架

• 支持FLASK的LSM框架(Linux Security Module),
• LSM的实施
  • 关键数据结构的修改
  • 钩函数的调用

注意: LSM只提供对钩函数的调用，具体钩函数的完善需要各安全模块完成。

• 安全系统调用
• 安全模块管理
• 相当于加了一层Proxy，由于Proxy过于“中心化”，也可能会导致一些其他的问题。

5. 安全系统开发方法

5.1 安全系统的开发方法

• 安全系统设计原则
  • 特点
  • 机制的经济性(Economy of mechanism)
  • 基于“许可”的安全(Fail-safe defaults)
  • 完全的访问仲裁(Complete mediation)
  • 开放型系统设计(Open design)
  • 权限分离(Separation of privilege)
  • 最小特权(Least privilege)
  • 公共机制的最小化(Least common mechanism)
  • 用户友好(Psychological acceptability)
• 安全操作系统的开发方法(Kernel Implementation Strategies)
  • 安全内核与传统操作系统设计比较
    • 设计安全内核要用到常规的操作系统的设计概念。
    • 不同的是，在设计安全内要优先考虑三个原则。完整性、隔离性、可验证性。
  • 安全内核的开发方法。
  • 早期的开发方法。
  • 改进/增强法分析，优缺点。
  • Identical Operating System (Virtual Machine)
    • 虚拟机法：在现有操作系统与硬件之间增加一个新的分层， 作为安全内核，操作系统几乎不变地作为虚拟机。
    • 优缺点
  • Compatible Operating System (Emulation)
    • 仿真法：对现有操作系统的内核做面向安全策略的修改，然后在安全内核与原ISOS用户接口界面中间再 编写一层仿真程序。
    • 优缺点
  • New Operating System
    • 新建法：包括面向安全策略的安全内核在内，重新设计整个操作系统
    • 优缺点
• 开发过程模型(Development Model)
  • CC提供的评估对象开发模型

6. 操作系统与虚拟化安全实现&

6.1 操作系统安全实践

• 安胜OS系统设计
  • 设计目标-v3.0
  • 设计目标-v4.0
• 系统总体结构
• 关键技术实现
• 多策略安全模型的建立
  • 多级机密性安全模型（DMLR_MLS）
  • 完整性保护模型(DTE_IPM)
  • 最小特权控制模型(PCM_RBPC)
• 支持多策略的安全体系结构/框架
  • 策略实施
  • 策略重用
  • 策略共存

针对支持FLASK体系结构的LSM框架无法灵活支持“策略重用”和“策略 共存”的问题，提出了一种支持多策略的、由”策略等价、策略冲突和策 略协作”组成的安全体系结构。

• 安胜OS多策略组合器的决策算法
• 功能描述与半形式化规范
• 安全机制的设计和实现
  • 用户标识与鉴别
  • 自主访问控制
• 实现的技术要点
• 安全机制的设计和实现
  • 强制完整性访问控制
  • 强制机密性访问控制
  • 最小特权控制
  • 隐蔽通道分析
  • 密码服务

6.2 系统虚拟化平台安全实践

• 系统虚拟化平台安全性分析
  • 安全机制的实现
  • 安全机制的漏洞
• 虚拟机监控器安全体系结构
  • XSM
    • 适用于Xen的通用安全框架
  • 框架接口目标
  • XSM的合理性
• 新的使用模型
  • 用于分解Dom0
  • 用于划分资源
  • 用于保护平台免受第三方软件攻击
  • 用于保护平台核心的安全服务
• XSM安全的好处
  • 安全功能的封装
  • 安全功能的扩展
• XSM的实现
  • 安全功能
  • 安全模块
• XSM特有实现
• XSM的模块管理
• 已实现的XSM模块
• XSM钩子
  • 做什么
  • 钩子放置方法
  • 目前的钩子位置
• 性能分析
• ACM 模块
• Hooks函数
• ACM STE策略
• ACM 中国墙策略
• Flask 模块 -> Flask 如何使用XSM
• 虚拟机安全迁移机制
  • 虚拟机迁移的好处
  • 动态迁移技术
  • 虚拟机动态迁移方法
  • 基于可信第三方的安全迁移协议实例
  • vTPM实例在硬件平台之间的安全迁移协议实例
• 虚拟机安全监控技术
  • 概述
  • VMI技术
  • VMWare VMSafe安全框架
  • XenAccess 安全API
• 虚拟机之间的隐蔽通道分析
  • 概述
  • 虚拟化平台上的隐蔽通道类型
    • XenCC－基于对mfn2pfn映射表读写的隐蔽存储通道
    • 基于CPU负载的隐蔽通道
    • 基于共享内存的定时隐蔽通道

6.3 虚拟可信平台技术

• 主要内容

  • 可信计算技术概述
  • 虚拟可信平台架构
  • TCG VPWG工作组
  • 虚拟可信平台关键技术

• 可信计算

  • 概念
  • 可信平台模块TPM
  • TPM提供受保护的功能和被隔离的位置

• 可信计算平台

  • 构成
  • 通过TPM硬件对软件层次的攻击进行保护，可以使用户获 得更强的保护能力
  • TPM不仅能在各种终端系统中建立可信链，还能将可信链扩展到网络中

• 完整性度量架构IMA: 该模块度量每一个加载的应用程序，运行 库以及内核模块。

• 可信软件栈

  • TPM设备驱动程序(TDD)
  • TPM设备驱动库(TDDL)
  • TSS核心服务(TCS)
  • 与TSS服务提供者(TSP)

• 虚拟可信平台架构

  • TPM虚拟化
  • vTPM的实现结构

• 为了保持TPM安全属性，设计虚拟化TPM必须解决以下四个问题。

• 开源软件资源，基于开源软件的虚拟可信平台架构

• TCG VPWG工作组

• 虚拟可信平台关键技术

  • 关键技术之一 信任链扩展
  • 关键技术之二 远程(递归)证实
  • 关键技术之三 迁移授权与vTPM迁移

6.4 Linux安全增强实践扩展

• 主要内容
  • eBPF机制
    • 演进
    • 工作原理
    • eBPF和Linux内核模块的区别
    • eBPF的局限性
  • seccomp机制
    • seccomp的引入背景
    • 机制工作原理
    • 内核实现
  • namespace机制
    • namespace机制的引入背景
    • namespace类型
    • namespace生命周期
    • namespace实例
    • 内核实现
  • cgroup机制
    • Cgroup机制的引入背景
    • cgroup控制资源分配的实例