操作系统是计算机系统的基础软件，而系统虚拟化已成为云计算平台的核心技术，没有它们提供的安全性，这些计算机系统及其上数据的安全性都将无法保障。本课程将从理论与工程实践相结合的角度，介绍操作系统(Linux)与系统虚拟化(Xen)安全相关理论、技术和方法，包括：安全概念、安全机制、安全模型、安全体系结构、安全开发方法、安全标准与评测方法等，帮助你深入学习和理解该领域的知识体系、实践技术和方法。
8.3 Flask安全体系结构-客体管理器（22:18）
Loading...
From the course by Peking University
操作系统与虚拟化安全
7 ratings
From the lesson
安全体系结构
Meet the Instructors
Prof. 沈晴霓 (Shen Qingni), Ph.D.
Dept. of Information Security, School of Software and Electronics（北京大学软件与微电子学院信息安全系）
[音乐]
[音乐]
同学们好
上一课呢我们讲到了这个GFAC这个体系结构 那么今天我们要讲的是Flask体系结构
那么Flask体系结构事实上就是我们前面曾经提到过的DTOS项目里面的
一个体系结构，那么它是针对的微内核系统下 建立的这样的一个安全体系结构，所以它叫
flux 的高级安全内核 那么这个体系结构呢在 DTOS
设计出来的时候 它呢主要是解决了前面刚才我们提到的GFAC里面没有解决的一些问题
比如说前面的这个GFAC主要针对的是多策略 但是它并没有针对的是动态多策略。
另外一个呢是 前面的GFAC是把这个策略实施和策略决策进行了分离
这是它的一个主要工作，但是它并没有去考虑这个 性能的问题，就是没有考虑如何提高这个，加入了这个
有这个体系的结构的时候怎么样考虑它的这个效率也很好，性能比较高 另外呢，就是说在这个体系结构里面
在GFAC里面并没有考虑这个权限吊销或者是撤回这样一些问题
那么这个Flask体系结构呢其实就会考虑这些问题
所以我们来说一下这个Flask体系结构它的主要的一些包含的内容
首先呢，它是支持多种安全策略，那么这个是跟GFAC一样的 第二呢，它可以实现细粒度的访问控制，比如说这个
框架其实主要也是支持访问控制的，那么其实这个跟这个 GFAC也是类似的。
那第三个呢其实是说它能够保持这个安全策略 和这个权限的授予之间保持一致
这个其实是指的，就是说我的这个系统里面的策略 是可以动态变化的。
第四条其实就是说权限是可以撤销的 那么也就是说我曾经授予的它的权限，可以动态地通过一些方式
比如说这个体系结构里面会提供一些interface，一些接口
明确地告诉我可以怎么样去撤销之前所 授予的权限。
这是Flask体系结构的 一个总体结构图，这个总体结构图其实非常简单啦，同学们可以看到
它主要包括两个组件，两大组件，第一个组件叫OM，叫客体管理器
第二个呢叫SS，叫安全服务器 那么这两个功能其实非常类似于GFAC里面的这个，就是
就是执行组件和这个决策组件，对吧
当然了，在这个FLASK体系结构里面，对这两部分其实是做出了更多的、
更详细的 这样的一个描述，包括它的这个相关的一些功能
就是它的组件以及这个相关的接口 描述等等，都做了更详细的一个刻画
这是刚才我们提到的，就是FLASK体系结构的组成部分，就是OM和SS
OM呢是负责这个实施安全策略 那么SS呢是负责这个安全策略的决策
对应前面的AEF和ADF
那么FLASK体系结构它就是要去描述这个OM和SS之间的这样一个交互
以及它们内部组成部分的要求
也就是说怎么样，就是一个是描述OM自己内部有些什么样的功能要提供
SS要提供什么功能，以及这两者之间如何交互，对吧？ 这就是FLASK体系结构的主要功能
那么接下来我们来分别介绍一下OM和SS的功能
我们先来介绍一下OM，就是客体管理器它主要提供一些什么功能
那么OM的主要的功能组成呢是有三部分，呃，有三部分
第一部分其实就是，大家知道OM叫客体管理器 所以它主要就是要帮助用户提请求是交给OM的
那OM当然，比如说它用户会有几种请求的类型 有三种请求的类型，比如说一个是它想访问某个资源
这个叫访问请求，因此它要给它提供一个 相关的一个功能。
第二个呢，是关于用户想去创建一个新的资源 那么创建一个新的资源的时候呢，要为相关的资源打上相关的
安全标签，对吧？或者说赋予相关的安全属性，这个其实是标记 的这个要求。
第三个请求呢可能是 对于用户呢可能有一些这个多实例化的一些需求
也就是说对于一些资源 它可以单一的一个资源，它可以把它实例化针对不同的用户
这是一个多实例化的一个要求。
那么，所以第一条就是 为客户端去提供访问决策、
标记决策和多实例决策的这样的一个接口，这样一个接口 那么这个接口其实就是来指向
真正的这个后面的ISS服务器来提供对应的这样的一个决策的
去请求这样的一个决策，然后返回相关的结果的一个接口
第二个呢是提供一个访问向量缓冲器AVC 这一点其实就是跟GFAC很大的一个不同
那么前面我们提过这个GFAC的 AEF每一次请求都要去咨询ADF
那么在这里的话，这个FLASK体系结构在这个OM这一端会增加一个AVC的一个
缓冲器，缓冲器，这个缓冲器里面存放的是什么呢？存放的是之前用户请求过的一些
这样的访问请求的一个决策结果。
假如某一个请求曾经发生过 下一次再请求的时候，它不用去直接咨询SS，就可以从AVC里面直接去查询
这样的话，就可以提高这个访问决策的一个效率
第三呢就是提供了接收和处理安全策略变动通知的能力
也就是说这个策略，SS服务器这一端的策略如果发生了变化
那么这个变化事实上应该有，应该在这个 OM这一端有办法，有接口可以去接收这样的一个变化的通知
对吧？那么这样一个接口它要提供，这是OM要做的三件事情
我们先来看一下，就是，重点看一下就是它提供的这种三种这样的
决策的接口，决策接口。
第一种决策呢其实就是关于这个标记决策
标记决策其实在讲标记决策之前，我们先来解释一个
概念，就是说在 因为我们说的这个体系结构，它希望是支持多个安全策略
那么而且是希望支持动态安全策略，所以策略是可以变的 那么策略可以变，那么为主客体打的这个安全标签
可能就不是一个固定的一个变量 也不是一个固定的变量类型，对吧？所以在系统的策略发生变化的
时候，我要让这个类型仍然可以支持不同的这样的变量类型
如何来维护这样的客体和安全上下文之间的这样一种关系呢 这就是我们第一个要解决的问题。
那么这个问题呢，我们 可以仔细思考一下，其实在不同的这个系统里面，我们
能不能找到一个公共的类型，这种类型可以去 让它根据不同的安全策略变成具体的相关的类型
比如说同学们学过C语言的话，会知道，C语言里面有一个vord，就是v-o-i-d这- 样一个类型
这个类型呢其实是一个空类型，对吧？那么用户在这个创建一个新的
变量的时候，它是可以把这个void类型，比如说void指针
可以把它强制转换成，比如说整型，强制转换成字符串型，对吧？这样都是可以去做的
那么在我们这个体系结构里面，其实我们也是要做这样一些事情
我们可不可以定义这样的一种类型，可以让它去达到这样一个目的
那么FLASK体系结构呢其实是考虑到这个问题呢给出了对这个
怎么样去标识客体呢，给出了这样一个分开的一个说法
第一个呢就是把这个客体标识成两个组成部分，第一个叫安全上下文
而且定义成一个可变长的一个串，这其实就是我们真正的安全属性这一部分
但是这一部分的解释呢不是由这个 OM去解释，而是由这个策略的应用程序或用户来解释
另外一个是安全标识，叫SID 这个SID事实上是在这个FLASK体系结构里面定义的一个固定长度的一个值
比如说是一个整数，对吧？这个整数其实就是一个标号 那么这个SID和这个安全上下文的
这映射关系是由来谁负责呢，这个映射关系交给安全服务器。
也就说客体 OM 这个就是客体管理器，它只知道这个 SID。
那么真正的安全上下文谁知道呢？安全服务器。
那么安全服务器需要把这个 SID 映射到对应的这个安全上下文。
这是对于这个数据类型的这个 为了支持多策略，它的一个表示，在 Flask 体系结构里面做的考虑。
接下来我们具体看一下这个客体标记决策的这个图。
那么从这张图上大家可以看到，就是说这是 client 这一端，比如说有一个主体。
这个主体呢，它的 SID，它的 SID 传给这个 OM。
OM 的话会通过这个请求，去
把这个请求转给这个 SS 服务器。
那么现在就是说，我们为了让这个 Flask 体系结构明确的规范
了，就是说我这边 OM 要提供给这个 SS 的这个接口
是什么，那么这里我们看一下，就是 OM 呢首先要获得这个新客体的 SID。
然后向 SS 去发这样一个请求，那么这个请求里面要携带的参数应该包括就是，
客户 SID，就是说发请求的这个主体的 SID 是什么。
然后它要创建就是相关的客体的 SID。
相关客体 SID 就是说，比如说你要创建一个新的客体，
那么这客体是在哪个父目录下面创建一个子目录或者创建一个文件。
对于这个父目录，其实就是它的这个相关的客体，对于这个父目录的 SID ，那么你要给出来。
另外你要创建的是，比如说你是创建文件还是创建目录，那么第三个参数是这个客体的类型。
那么 SS 服务器呢会引用这个相关的这个策略逻辑，就是标记逻辑，
叫标记规则，在这叫这个 label 的 rules。
那么通过这个规则，根据它的安全上下文，然后来
返回一个，就是首先它计算出它这个客体应该给它的安全上下文是什么。
然后通过这个安全上下文计算出它的 SID。
再把 SID 返回给这个 OM。
所以 OM 呢，会将这客体 得到这个 SID
之后，把这个 SID 跟它的那个新建的客体 绑定在一起，这就是客体标记决策。
那么在这里其实重点要说的就是说，OM 服务器要提供了一个相关的这个咨询，
这个 SS 服务器的一个接口，一个接口，同时要返回的是 这个 SID 的值。
那么第二种这个决策呢，是这个访问请求，或者说和这个 AVC
的缓存的 安全决策，那么从这张图上大家可以看到，
在 OM 这一端其实是多了一个 AVC 的这样一个缓存项量结构。
那么这里其实指的就是用户提出 一个请求去读，或请求去写，或者执行一个客体的时候，
那么这样一种请求类型，这种请求类型客户会对 OM
里面存在的这样的一个，比如说我们这里给的这样一个例子是， 就比如说一个客户请求对某一个客体进行修改。
这是一个请求操作，访问操作。
那么 OM 这客体管理器呢，会去首先会去咨询 AVC 这个项量表。
看看这个表里面有没有曾经这个客户 SID
对这个请求的这个客体的 SID
的一个写的一个请求，允许的这样的一个一个项。
如果有个话，就直接返回，如果没有 它再把这个访问请求转给这个 SS 服务器。
那么这个访问请求里面当然带的是， 就是我们的这个 SID ，就是请求客户 SID。
和这个请求访问资源的 SID 和请求访问模式，这三个参数要传递给 SS 服务器。
那么 SS 服务器通过这个策略逻辑，就是它的安全策略的这个逻辑。
那么以及它的这个安全上下文，然后 去判定以及安全规则，就是这个
policy 的这个，就 access ruling，就 rule。
这些规则来决定它是允许还是不允许。
如果决定允许就返回这样一个结果。
这个结果会传送给对方的这个 AVC。
那么 OM 这一端的 AVC 会记录下这样一个决策结果。
下面我们看一下这个支持多实例化的这一部分。
那么支持多实例化这一部分其实主要是，对于系统里面的一些特定的一些资源，
它希望做一个划分，就是说让不同的这个终端看到这个资源的不同的这个
就是群组，群组，那么使得好像同一个这个，同一个这样的一个资源。
用户所看到其实是不同的这样的一个视图，这视图，这其实多实例化的一个做法。
比如说在这个 Linux 操作系统里面有一个 tmp 的目录
那么 tmp 目录呢，其实是可以为所有的这样用户
去使用的，那么比如说它可以针对在系统里面不同安全级的用户， 他看到的这个
tmp 目录的这个内容是不同的，这个其实可以做到一个多实例化的一个效果。
这就是它的概念，那么我们在这个，在这个请求决策，在 Flask
体系结构里面，它也给出了这样一个 就是请求的模式，这种请求呢，就是说客户呢
首先他会请求去创建一个，就比如说就是在 tmp 目录下要去创建一个客体对吧。
那么他只能够在他所看到的那个视图里面去创建。
所以他要知道，要找到这个实例化的这个位置和它对应的 SID 是什么。
所以客户呢，向这个 OM 请求创建一个新的客体。
当然这是一个多实例化的客体，那么在请求里面 要携带上这个请求的客户的 SID。
多实例化这个客体的 SID 和这个它要创建的这个客体类型的 比如说是目录还是文件，对吧，这样一个参数。
那么 SS 服务器呢，会去根据这个多实例化的这种规则。
去决定给这个要创建的这个客体分配一个什么样的安全上下文。
那么这个安全上下文对应什么样的 SID。
那么之后呢 SS 服务器会把这个 SID 返回给 OM，那么 OM 要把这个
SID 跟它的这个 就是选择一个成员来创建，跟这个 SID 绑定在一起。
这是多实例化的这个方法，那么 Flask
体系结构 第一个，刚才说到的这 OM 的功能的第一个就是多个，支持多个决策的这样一个接口。
第二呢其实就是刚才其实也涵盖就是 AVC 的这个部分。
那么其实第三个部分呢，就是刚才我们提到的就是说，它要支持一个策略变通的这样的一个通- 知的，接受策略
变化的一个通知的这样一个能力。
所以这个能力其实就是为了支持这个策略吊销的。
那么我们来看一下，如果在，要支持策略吊销，在安全策略 发生改变的时候，那么
OM 和 SS 之间是其实是要做交互的。
要做交互的，那么这种交互呢，在这个 Flask 体系结构设计的时候希望它是一个原子性的一个操作。
原子性操作，所谓原子性的操作当然就是希望这种操作要么成功，要么就 失败，对吧，这样一种操作。
所以呢，在这个 Flask 体系结构设计的时候呢， 对于这个策略变通，或者说我们说策略吊销这个机制。
它希望能够满足就是这样一个 协议，就是 OM 和 SS 之间能够满足这样的一个三步的协议。
哪三步协议呢，第一步就是说 SS 可以让所有的
OM 去注意到这个以前策略的任何部分发生的变化。
也就是说呢，SS 如果策略发生了变化，它一定要让 OM 知道。
也就说它一定要有一个通知的这样一个接口。
第二个呢，就是 OM
这一端， 每一次都能够去更新，就是说接到这样的通知之后，
它能够去有相应的功能去更新它的内部的状态， 来反映这个策略的变化。
第三个呢，就是 OM 更新完自己状态之后， 比如说它响应完这边的这个变化通知之后。
它就应该告知这个 SS 我已经
更新完毕，更新完毕，所以这是关于这个吊销 OM SS
之间应该做到的这样一个交互的协议。
这个吊销刚才我们提到了，在这个 Flask 体系结构，它希望它是
一个原子性的一个操作，而且希望是一个实时性的，满足实时性的要求。
比如说不希望策略变了，这边更新就是很后，就是很后的时间才进行更新，对吧。
希望它能够实时的进行更新。
那么，因此为了实现这样一个更新的话呢， 其实在 OM
这一端，要做一些很细微的一些要求，提出了一些很细微的一些要求。
比如说在微内核里面，它要考虑就是 OM 和
SS 之间 这样一个实时通信，就是要通信效率很高。
要互相及时的通知，和及时的告知对方我的这个更新状态。
第二呢就是说，这个调度程序要配合。
因为大家知道，这边发了通知，这边响应不到，比如说它拿不到 CPU
的调度 资源，它也没有办法去工作对吧，所以这个 CPU
呢要尽量的要分给 这个 OM，让 OM 能够及时的去响应这个吊销策略的变化。
这就是微内核体系结构的一个吊销的一张图，那么这张图里面其实 给出的是关于这个
OM 这一端，可能要考虑的 就是 AVC
里面相关的一些这个表象，就是之前决策的一些表象。
比如说之前这个策略是允许的，那么接下来变化的这个策略是不允许。
所以你要把之前的这个表象 内容要做一个更新，那么可能这个内容已经在
内存里面，那么要想办法去更新这个内存里面的这个表象的内容。
另外呢，还有一些可能是已经开始在工作的。
就是说通过这个决策允许的，那么决策允许以后，它已经在开始执行这个访问操作。
那么对于这种情况，应该怎么样进行更新，这是关于这个 在吊销的时候要考虑的两个问题。
Fluke 的这个 API 就是关于这个吊销的这个 API 呢，其实有两个性质。
这两个性质呢，其实是对这个吊销机制做了一个简化。
比如说它提供了这个线程状态的这个及时的
和这个完全的一个输出，就是在线程这个级别，对这个 策略性吊销。
另外也确保内核的操作，或者是原则性的，或者是可以
清楚地细分为用户可视的这样的一个原子性的一个阶段，其实原子性的一个要求。
好，这部分我们就讲到这儿，下一次课呢我们会讲一下 SS
安全服务器的组成，谢谢。
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2019 Coursera Inc. All rights reserved.
