基于服务体模型的安全操作系统中的通信与安全控制

基于服务体模型的安全操作系统中的通信与安全控制吴明桥基金项目: 本文受到国家自然科学基金项目(60273042)和安徽省自然科学基金项目(03042203)支持。作者介绍: 龚育昌，女，博士生导师，1943-，研究方向数据库，算法，操作系统，超媒体；吴明桥，男，博士研究生，1978-，研究方向安全操作系统；李宏，男， 博士研究生，1975-，研究方向操作系统；，李宏，龚育昌中国科学技术大学计算机科学技术系，合肥，230027Email: wu_bridgeustc.edu摘要：本文在扼要介绍基于执行流/服务体的操作系统模型的基础上，重点讨论了基于该模型的安全操作系统中的通信机制及其安全控制。分析了通信可能受到的威胁，并给出了相应的对抗方法，从而简便有效的保证了操作系统的安全性。关键词：安全操作系统 服务体模型 执行流 服务体间通信中图分类法： TP316 文献标识码：AInter Serverblock Communication and Its Security in Serverblock Based Secure Operating SystemWu Mingqiao, Li Hong, Gong YuchangDepartment of Computer Science and Technology of USTC, He Fei , 230027Abstract: Based on introducing the novel serverblock model of operating system, the paper discusses the communication mechanism and the security control of a serverblock model based secure operating system in detail. Then the analysis of threats to communication and the countermeasures to ensure system security efficiently are presented as well.Key words: secure operating system, serverblock model, executive-stream, inter serverblock communication1引言操作系统的安全性是保障信息安全的基本条件，日益受到人们的重视。日益复杂的外部环境要求安全操作系统必须具有灵活的体系结构，满足动态的、多样的安全策略。但是安全性和效率往往是矛盾的，增加安全控制必定会带来一些开销，甚至影响系统的易用性。因此，如何开发一个安全、灵活、高效的安全操作系统成了人们的追求目标。传统的基于微内核结构的操作系统灵活性高，但是由于上下文切换频繁，效率较低。单内核结构的操作系统效率很高，但是不够灵活。我们在分析传统操作系统结构的基础上，提出了一种基于执行流/服务体的操作系统构造模型3,4。该模型引入了执行流和服务体等新的系统抽象，保持了微内核结构的灵活性，同时极大的增强了系统效率。其固有的灵活性可以方便有效的支持各种安全机制，如易于支持flask安全体系结构1。在执行流/服务体模型中，传统的进程间通信被服务体间通信取代。服务体间通过一系列“端口”传送消息。本文在扼要介绍执行流/服务体模型结构的基础上，重点讨论了服务体间通信机制及其安全控制。分析了服务体间通信可能受到的威胁，并给出了相应的对抗方法。所提出的上述技术可以简便有效地支持操作系统的安全性。2服务体模型执行流和服务体是服务体模型的两个基本抽象。执行流是CPU执行能力的抽象，服务体是代码和数据的集合体。执行流的流向由服务体的代码指引，服务体由执行流推动执行。操作系统中各功能模块如文件系统、内存管理器、驱动程序等都以服务体的形式存在。服务体模型的逻辑结构如图一所示：2.1执行流执行流是系统的动态部分，是CPU执行机器指令能力的最原始的抽象。每个CPU提供一个执行流，如果采用超线程技术则每个CPU可以提供多个执行流。执行流是比线程更加基本的抽象，它是一个连续的概念，从处理器上电复位到关机时结束，中途不会被阻塞、挂起和停止。执行流不与固定的地址空间绑定，其作用就是推动服务体完成消息处理，从而可使执行流能够直接跨越系统组件边界（往往是地址空间边界），而不必像微内核模型那样必须使用不同的线程。2.2服务体服务体是系统的基本组成单位，是具有通信功能，拥有地址空间、安全控制等资源和属性的能够完成某种功能的代码和数据集合。用户程序（包括驱动程序）的各种功能组件都以服务体的形式存在。服务体是一种静态的概念，其生命周期不依赖执行流，具有持久性。服务体拥有一系列端口，端口又包含一系列小端口，服务体间通过给端口或小端口发送消息进行通信, 在执行流的推动下进行消息处理。服务体的地址空间分为基本空间和扩展空间两部分，每个服务体具有一个基本空间和一个或多个扩展空间。不同服务体的基本空间相互隔离，但在使用上作为整体统一分配，逻辑上在同一段空间中，彼此占用不同的地址区间，互不重叠。这个特点使得一个服务体的基本空间的内容很容易映射到另一个服务体的基本空间，从而共享带有指针的复杂数据结构。扩展空间为服务体所私有，空间中的内容可以交换到后备存储器中以优化系统内存的使用。服务体将大的私有数据和运行时期所需要的运行库加载到扩展空间中，需要共享的复杂数据加载到基本空间。一个服务体可以拥有多个扩展空间，从而使所管理数据的容量超过受硬件限制的虚存空间。服务体间数据共享按照不同的属性可分为共有共享、写时拷贝共享和转移共享。服务体A服务体B扩展空间基本空间 图二 服务体地址空间运行库 数据 代码或共享数据图一中标识的执行流/服务体管理器由核心服务体实现。核心服务体逻辑上相当于传统操作系统的内核，负责提供服务体间通信机制、执行流/服务体的管理、中断和异常等服务，以及维护关键抽象的数据结构。服务体模型中没有所谓的内核空间，核心服务体同其他服务体一样，拥有独立的基本空间和扩展空间。核心服务体可将通信相关的代码和数据以只读的方式共享给其他服务体，既使得其他服务体能够直接利用这些共享的代码和数据发送消息，又不能破坏它们。3服务体间通信服务体间通信机制是服务体模型的基础机制，具有三个基本抽象：消息、端口和小端口。服务体之间通过端口、小端口传递消息，提供或获取服务。服务体间通信可以将持续流动的执行流分派到不同的服务体中以实现系统的并发，并且具有位置无关性，可以透明的扩展到分布式环境中。3.1 端口和小端口服务体的每个端口对应服务体提供的一个消息处理例程以及描述该例程的一些信息（如优先级、地址空间标志符、处理器特权级等）。服务体可以用一个端口代表一个它所维护的对象（如文件，Socket，设备等）。其他服务体通过向该端口发送消息来操作该对象而不必关心它所在的位置，利用这种位置无关性服务体的服务透明的扩展到分布式环境下。一个端口包含一个或多个小端口。小端口包括寄存器上下文和堆栈地址、状态标记等。寄存器上下文包括所有的通用寄存器以及控制寄存器，用以保持服务体通信过程中的现场。堆栈是消息处理程序运行时所需要的，可以在基本空间也可以在扩展空间。该堆栈地址与端口中的地址空间标志符相对应。执行流只能从小端口进入一个服务体的内部，根据记录在端口以及小端口中的信息进行资源和状态的切换，并由端口对应的消息处理例程完成消息的处理。端口和小端口数据结构由核心服务体负责管理，核心服务体为服务体的每个消息处理函数生成一个端口和若干个小端口。服务体在向一个端口发送消息之前，必须首先获得该端口的发送权。客户服务体通过系统中的名字服务器（维护端口权力的授权）得到目标服务体的端口权力。端口权力代表了端口的一个名字。名字空间对于服务体来说是局部的。因此不同的服务体对于相同的端口具有不同的名字，而相同的名字在不同的服务体中可能代表不同的端口。在这个意义上端口名字和UNIX中的文件描述符是类似的。端口权力可以通过消息在服务体间传递，因此任务可以多次得到同一端口权力。服务体通信机制保证每次都使用相同的名字。这样，任务可以比较两个端口名字，如果他们不匹配那么他们指的不是相同的端口。核心服务体为每个端口权力维护一个变换项，用以管理四元组的集合。其中服务体指的是拥有权力的服务体，局部名字指的是在服务体中端口的名字，端口和小端口是指向各自数据结构的指针。核心服务体进行两种变换：到局部名字的变换以及到端口/小端口的变换。3.2 消息消息是有类型数据的集合，具有确定的格式，由消息头部和数据部分组成。消息头部包括消息号，目的端口、应答端口，以及消息类型和大小。消息号表明了对端口的操作种类。内存管理服务体负责分配和回收消息。服务体发送消息时，先申请一个物理页，填写完毕后调用消息发送原语发送消息。消息内存的映射从本服务体的空间转移到目标服务体空间，因此目标服务体可以直接使用消息中的内容。使用完毕后可以再次利用（如作为应答消息使用）也可以回收（不再需要）。为了有效地进行消息内存管理，内存管理服务体将所有的物理内存连续影射到其基本空间内，并在分配消息时从该空间内分配一个物理页，并以读-写方式与请求服务体共享。得益于基本空间的管理规则5，内存管理服务体维护这种共享时可以直接将该物理页映射到目标服务体的基本空间中的相同地址，而不必担心该空间是否可用。消息在服务体之间的传递实际上是共享映射的变化，节省了拷贝消息的开销，因此具有很高的效率。消息有三种基本类型：（1）普通数据。不用核心服务体解释，由接收者负责解释。消息处理例程所需的参数可以以此传递。（2）脱机内存。使用共有共享、写时拷贝或转移共享等方式在发送者和接受者之间共享大量数据。需要核心服务体通知内存管理服务体修改地址映射关系。（3）端口权力。包括发送权和一次发送权。需要核心服务体维护端口和局部名的映射关系。对三种消息的处理方式如图三所示。端口P2服务体B消息（a） 普通数据的传递对象服务体A 端口P2服务体B消息（c） 端口权力的传递服务体A端口P1消息图三 消息传递脱机内存端口P2服务体B消息服务体A服务体C服务体D（b） 脱机内存的传递3.3 消息传递接口消息传递的编程接口只有一个：msg_body_t* msg_send(msg_body_t* hdr, msg_option_t option);服务体模型中没有消息接收函数，因为消息的处理是由执行流调用端口中的消息处理函数被动完成的，从这个意义上说，服务体随时做好了处理消息的准备。当执行流通过一个小端口进入服务体时，该小端口被标记为忙。标记为忙的小端口是不允许执行流再次进入的，否则会破坏堆栈中的内容而造成错误。服务体可以使用三种不同的消息传递方式： （1）同步-连续方式。发送消息，执行流立即进入其他服务体，完成服务后返回继续执行，msg_send返回应答的消息。进入其他服务体前需要将当时的寄存器上下文保存在进入当前服务体所用的小端口数据结构中，并将该小端口作为应答端口传递给目标服务体。这种特殊的应答端口只能被应答一次，对它的发送权称为“一次发送权”，发送一次消息后即丧失该端口权力。核心服务体对一次发送权和发送权分开维护，具有不同的变换项，指向小端口的变换项代表一次发送权。如果一个服务体同时对一个端口以及该端口的一个小端口拥有发送权和一次发送权，它将具有两个不同的局部名字。一次发送权可以避免服务体端口名字空间膨胀，节省释放端口带来的额外开销，以及满足客户安全方面的期望（希望服务器不要永久地持有端口权力）。（2）同步-分离方式。发送消息，执行流立即进入其他服务体，完成服务后应答到指定的端口。进入本服务体被标记为忙的小端口将被重新标记为空闲，因为执行流由指定的端口引导执行，不会回到离开点。提供服务的服务体处理完消息后，如果该消息需要应答则向指定的应答端口发送消息，否则向核心服务体发送消息以放弃执行流，这两个消息是不需要对方应答的。（3）异步方式。发送消息，执行流继续在本服务体内执行，消息被异步的处理以及应答。核心服务体选择一个空闲的小端口挂在其维护的一个等待队列上并将消息与其关联起来。在以后的小端口调度的过程中，核心服务体会选择并使用该小端口处理消息。4服务体间通信的安全控制4.1 安全控制机制服务体模型中，每个服务体都是一个保护域，执行流在进入该保护域时需要接受检查。不同的服务体具有不同的可信程度。系统的可信计算基由少量系统服务体组成，这些服务体称为可信主体，用户服务体则构成了不可信主体。可信主体常常需要直接与不可信主体交互，例如，文件服务体必须接受来自不可信主体的请求。端口代表了各类对象，包括代表服务体本身，充当系统的客体。系统的安全控制即控制服务体对端口的操作。服务体间通信的安全控制点非常集中，只需要在发送消息时进行安全检查，这种检查由安全服务体完成。安全服务体实现MLS、TE和RBAC等安全策略。安全服务体将代表自己的端口权力传给其他与安全相关的服务体，它们通过给该端口发送消息请求安全判定。服务体间通信的安全控制分为两层。一层是对端口权力的控制。服务体必须拥有目标端口的发送权才能向其发送消息，对端口没有发送权意味着不能对端口代表的对象进行任何操作；一层是对端口接收消息的控制。端口能接收的消息表示对其代表的对象可进行的操作种类，不同的主体对端口拥有不同的可发送的消息集合。例如不同的客户服务体对文件拥有不同的读写权限。客户服务体拥有的端口权力和可发送的消息集合构成了其对客体的权能。对象管理服务体提供权能管理6，权能的创建和传递需请求安全服务体进行赋值和判定。对象管理服务体提供权能即时撤消机制，因此主体使用权能时不再需要请求安全服务体进行安全检查。对于服务体间的消息传递，如图四所示，控制方式按照消息种类分为两种：(a)普通数据和脱机内存的传递。msg_send首先检查A可以对P1发送的消息集合中是否包含了本次的消息。消息号表示了本次操作种类，脱机内存是一种特殊数据，需要核心服务体请求内存管理服务体改变内存映射。(b)端口权力的传递。传递端口权力同时传递对该端口可发送的消息集合，安全服务体对此传递进行控制。图四 消息传递的安全控制AB消息（a）普通数据和脱机内存P1 AB（b）端口权力A可以给B传递吗?安全服务体消息消息判定结果P2P3P44.2 安全控制实例图五表示了一个服务体发出请求读1M字节文件的处理流程。箭头表示了执行流的流动过程，经历了6个处理步骤。图中略去了核心服务体，把端口同服务体画在了一起。在发起读请求之前，客户服务体已经通过对象管理服务体获得了文件服务体服务端口A的发送权a。进一步说明如下：文件服务体 A CodeCode B data客户服务体图五 服务体模型消息通讯过程及安全控制扩展空间基本空间端口局部名内存管理服务体1 客户服务体申请消息，内存管理服务体分配一页物理内存T与客户服务体共享，如图五中虚线所示。为防止恶意申请消息占用资源，可采取定额控制。2 客户服务体使用物理页T作为消息，通过一个局部名a将消息发往文件服务体的服务端口A，同时指定一个自己的端口B作为应答端口。首先检查客户服务体能够发往端口A的消息集合中是否包含本消息（此处为读文件的消息），然后检查客户服务体是否能够对端口B发送消息，这是为了防止客户服务体错误指定其他端口。如果检查通过，则核心服务体负责将局部名a转换为端口A，并为文件服务体安装端口B的局部名b，消息映射转移到文件服务体中。3 文件服务体接收到消息并利用它向内存管理服务体发送消息申请1M内存。4 内存管理器在文件服务体的data区域分配1M内存，消息被重新发回，其中包含了分配到的地址。5 文件服务体进行I/O操作将文件数据读入分配的内存中，将该内存地址、大小等填入消息并标明类型为写时拷贝（COW）的脱机内存，然后使用局部名b将消息发回客户服务体的应答端口B。在此过程中，核心服务体除了做端口转换外，还要通知内存管理服务体将文件服务体指定的脱机内存以COW方式映射到客户服务体的空间，并根据结果重新改写消息中的地址信息。6 客户服务体从消息中得到数据地址并释放消息内存。整个过程仅使用了一个消息页。5服务体间通信面临的威胁和解决途径5.1 识别消息的发送者可信主体在面对众多不可信主体的请求时，需要防止恶意用户仿冒其他用户，因此必须识别请求者才能实现安全控制。传统的基于消息传递的微内核系统中，端口是一个消息队列，可以允许多个不同的发送者向它发送消息，因此无法通过端口识别发送者。一个解决办法是在消息中绑定发送者的安全上下文2，这样就需要增加在消息中指定不同的安全上下文的额外控制。服务体间通信不需要在消息中绑定发送者的安全上下文，因为发送者只有持有端口的发送权才能向该端口发送消息。发送者在申请服务时，对象管理服务体将请求安全服务体进行安全检查，通过后返回提供服务的服务体端口的发送权，不可能被假冒，因此具有可信性。恶意用户无法使用未授权的端口权力，因为核心服务体没有端口和局部名的变换项。执行流通过小端口进入服务体时，请求服务者的安全上下文记录在小端口中，需要时随时可以检索到它。这样把发送者的安全上下文与消息分离开来，保持了消息的独立性，防止消息被截取而泄漏访问控制信息，有效减少了系统被攻击的危险性。5.2 传输时保护消息不被篡改如果消息在两个可信主体间传送，不可信主体能够修改其内容，从而可能会欺骗可信主体滥用其权限。例如，一个可信主体检查文件，剔除敏感数据后给另一个可信主体发消息，使其把通过安全检查的文件向下分发。如果有不可信主体修改了消息，指定了另一个文件，就有可能造成敏感信息的泄漏。核心服务体在单机节点上能够保证消息的完整性。如果消息通过网络传输，网络服务体必须确保消息的完整性。如果通信链路被物理保护，那么只需采取可靠的传输协议即可，否则需要对消息进行加密。5.3 防止消息被截取服务体模型中没有消息的接收原语，端口权力保证了消息能够被正确地接收。因为对于特定的服务体来说，端口权力是唯一的，端口权力与端口是一一对应的，因此截取者无法通过端口截取消息。5.4 保证消息的传送如果一个主体（服务器）为其他主体（客户）提供可信的服务，应该保证客户始终能够发送请求给服务器，并且保证服务器能够发送信息给客户。例如，要防止一个不可信主体阻止其他主体访问文件服务器，以保证文件服务器对所有主体都是可访问的。在服务体模型中，用户只能使用授权的端口局部名发送消息。每个端口具有一个或多个小端口，每次请求服务使用一个小端口。这样，一个主体可以通过往一个端口发送大量消息，消耗掉所有小端口以阻止持有该端口的服务体为其他服务体提供服务。对这种隐患可以通过不允许不可信服务体直接向该端口发送消息的措施，对不可信主体进行定额控制。这样可以防止消息洪水方式的攻击。5.5 防止错误指示可信主体必须防止不可信主体向它发送错误的指示消息，欺骗它滥用权利。比如，安全级为秘密级的客户向服务器发送消息（服务器可以在秘密级和公开级上操作），指定的应答端口为公开级，这样信息便可以从秘密级流向公开级。有两种防止这种错误的办法。一是要求保证应答端口的安全级别至少和服务器的一样高，二是要求客户具有向应答端口的发送权。5.6防止隐蔽通道应当防止正当的操作序列产生不当的结果。例如，正常情况下，小端口用完时应向请求服务的主体返回“小端口用完”的信息。如果低级别的服务体向高级别的服务体请求服务得到该信息，则表明信息从高级别流向了低级别，这违背了信息的保密性，可能会被用来制造隐蔽通道。服务体模型对于这种请求直接返回，不对消息作任何处理，低级别服务体不能得知导致这次服务没有完成的原因，从而避免了信息的泄漏。6结论服务体间通信是基于服务体模型的操作系统的重要组成部分，本文详细介绍了安全操作系统中服务体间通信及其安全控制。文中提出的服务体间通信的安全控制分为两层，一是对端口权力的控制。二是对端口接收消息的控制。服务体间通信机制由核心服务体提供，因此是可靠的。安全判定模块由单独的服务体实现，与安全实施模块通过服务体间通信机制进行通信，具有形式统一，结构灵活的特点。系统中安全判定模块由对象管理服务体和安全服务体组成，可以支持多种安全策略。参考文献1. R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau. The Flask Security Architecture: System Support for Diverse Security Policies. In Proceedings of the Eighth USENIX Security Symposium, pages 123-139, Aug. 1999.2. T. Fine and S. E. Minear. Assuring Distributed Trusted Mach. In Proceedings IEEE Computer Society Symposium on Research in Security and Privacy, pages 206-218, May 1993.3. 李宏, 龚育昌, 赵振西, 吴明桥. 服务体模型与操作系统内核设计技术. paper/li2.doc（将在计算机研究与发展Vol.4,2004发表）4. 李宏, 龚育昌等. 基于服务体的操作系统体系结构. paper/li5.doc, 20045. 龚育昌, 李宏等. 服务体模型与地址空间管理. paper/li3.doc, 20046 龚育昌, 吴明桥等. 安全操作系统中的权能管理模型. paper/wu2.doc, 2004