专利名称：一种操作系统的访问控制方法及其实现平台的制作方法
技术领域：
本发明涉及一种操作系统的访问控制方法及其实现平台，适用于对多种操作系统
进行访问控制的方法及平台，解决了对多个操作系统添加访问控制时需要重复编写访问控 制模块的问题，提出了一种独立于操作系统的安全加固方法。
背景技术：
目前，主流的操作系统对访问控制的支持都不充分，例如Li皿x、 Windows等系统 只支持自主访问控制，普遍缺乏对强制访问控制的支持，故而需要对各种系统添加访问控 制机制以加强系统的安全性。目前访问控制在操作系统上的实施一般是针对单个系统，如 美国国家安全局(NSA)的SELi皿x项目针对的是Li皿x系统，江苏南大苏富特科技股份有 限公司自主开发的安全操作系统产品Soft0s也是针对Li皿x系统的。这些项目针对单个 操作系统，使得其访问控制模块难以被实施在多个系统上。
发明内容
为了克服背景技术中存在的不足，本发明提供一种可应用于多种操作系统的、灵 活的访问控制平台，并提供统一的策略配置方法，能方便地将其在各个操作系统上实施。
实现本发明目的的技术方案是提供一种操作系统的访问控制实现平台，其特征在 于它包括操作系统Hook层、平台抽象层和核心安全服务器； 所述的操作系统Hook层用于截获操作系统的请求，并提供给核心安全服务器进 行安全判断； 所述的平台抽象层包括平台支持的各种操作系统不同的操作集封装、内存对象封 装和内核API封装，为核心安全服务器提供平台抽象； 所述的核心安全服务器包括策略缓存模块、策略管理模块、安全上下文管理模块 和策略数据库；所述的策略缓存模块用于保存最近发生的对系统操作进程的判定；所述的 策略管理模块用于支持多种安全策略，并支持动态策略；所述的安全上下文管理模块主要 用于管理安全上下文；所述的策略数据库中，保存平台支持的各种操作系统安全模型的安 全规则，用于核心安全服务器对请求进行访问权限判定时提供依据。
—种操作系统的访问控制方法，其特征在于包括如下步骤 (1)操作系统Hook层将截获的请求发给核心安全服务器，由核心安全服务器的策 略缓存模块对该请求进行查询，判定在否有相同的请求存在于策略缓存模块中；如果有，直 接返回操作系统Hook层，执行该请求；如果没有，执行步骤(2); (2)查询核心安全服务器中的策略管理模块，依据策略数据库中保存的平台所支 持的操作系统安全模型的安全规则，判定是否有该请求的访问权限，如果有，则将该请求存 放在缓存中，并返回操作系统Hook层，执行该请求；如果没有，则返回不允许，拒绝该请求。
研究表明，对于实施访问控制，各个操作系统的不同点主要以下几点操作集不 同，内存对象不同和内核API不同，本发明所提供的与操作系统无关的访问控制实现平台平台，依据多种安全系统的实现以及访问控制相关的理论，将访问控制模块分为操作系统 相关部分和无关部分，将访问控制分作三部分操作系统Hook层，平台抽象层，以及核心安 全服务器层。操作系统Hook层的作用是监控系统的操作；平台抽象层的作用是抽出核心安 全服务器层依赖于系统的部分，使核心安全服务器可以应用到多个系统中；核心安全服务 器是实现本发明技术方案的核心部分，其作用是进行访问控制判定等。
与现有技术相比，本发明具有以下显著的优点 1、本发明采用平台抽象层的方法，扩展包括了对象管理器的封装，操作系统内核 API的封装和操作集的封装，核心安全服务器不依赖于操作系统操作的不同，也不依赖于操 作系统内核对象的不同，可以保护不同系统中不同的内核对象，不同的系统资源。核心安全 服务器独立于目标操作系统文件系统的实现，不管目标文件系统是否支持扩展属性，其都 可以对文件进行保护，使核心安全服务器能运行于系统内核，实现访问控制的功能。因此， 核心安全服务器可以被实施到多个操作系统中，并实现了动态多策略。 2、本发明采用平台抽象层的方法，抽象了访问控制模型的共同点，建立了一种安 全规则描述，可以支持目前已有的多数安全模型，为实施了核心安全服务器的操作系统提 供了统一的策略配置，方便了安全管理员对多种系统进行安全配置。 3、在新的操作平台上实施核心安全服务器时，只需要实现操作系统Hook层并扩 展平台抽象层，无需修改核心安全服务器。本发明制定了操作系统Hook层的实施标准，用 户只需要按照标准实现操作系统Hook层即可。
图1是本发明实施例操作系统访问控制实现平台的结构示意图；
图2是本发明实施例的核心安全服务器的结构示意图；
图3是本发明实施例的平台抽象层的结构示意图；
图4是本发明实施例的安全标签设置的结构示意图。
具体实施例方式
下面结合附图对本发明的具体实施作进一步描述
实施例1 在访问控制中，主体一般代表动作的发起者，客体代表动作的接受者。对于计算机
而言，主体一般指一个进程，而客体一般指进程、文件或Socket等资源。 对于"安全标签"或"安全上下文"，其概念即为安全模型的标签，这是安全模型进
行权限判断的依据。在本发明中采用"安全上下文"(context)来描述。每个安全模型都有
自己的安全上下文，对于操作系统中的主客体来说，其安全上下文是系统中加载的每个安
全模型安全上下文的集合。如一个实施了BLP、BIBA模型的系统中，进程A的BLP级别为1，
BIBA级别为5，则进程A的安全上下文为BLP、 BIBA安全上下文的集合{1， 5}。 对一个安全模型而言，其进行权限判定的依据一般是主/客体安全上下文及此模
型的安全规则。如BLP模型判定依据是主/客体的的敏感级别，安全规则是所谓的"上读下
写"规则；TE模型的安全上下文是主/客体的域/类型，其安全规则是域转移规则、域/类
型访问规则等。本实施例中，安全策略指某个安全模型的安全规则，对于BLP、BIBA等，均以安全模型表示。 操作系统访问控制的实现一般是通过监控系统调用，并通过访问控制核心模块进 行安全判定。访问控制核心模块使用主客体安全上下文以及安全规则做出判定，由于其需 要运行于操作系统内核，故而其依赖于部分内核API(如内存、锁操作)。由于各个系统实现 的不同，操作系统HOOK层的实现也不同，如Li皿x系统提供了可以作为操作系统Hook层的 LSM框架，而Windows系统并没有这种框架。为了抽出访问控制的无关部分，本实施例提供 了一个与操作系统无关的访问控制平台，能方便的将平台的核心部分实施到各个操作系统 上去，从而实现对不同操作系统的访问控制。 参见附图l，它是本实施例提供的操作系统访问控制实现平台的结构示意图，该平 台由操作系统Hook层、平台抽象层和核心安全服务器三部分组成。操作系统Hook层部分， 在本实施例中以Linux和Windows的实现为例，说明了操作系统Hook层所处的位置以及 作用；核心安全服务器包括策略缓存模块、策略管理模块、安全上下文管理模块和策略数据 库；平台抽象层为核心安全服务器提供操作系统抽象，使核心安全服务器不需要考虑各个 系统的不同。 参见附图2，它是本实施例的核心安全服务器的结构示意图；核心安全服务器的 策略缓存模块提高了核心安全服务器的性能，策略缓存模块中保存的是对最近发生的系统 操作的判定，这样极大的提升了核心安全服务器进行判定的性能；在核心安全服务器更新 策略时，可以通过清空决策缓存来实现策略的一致性，实现了动态策略。策略管理模块、安 全上下文管理模块以及策略数据库是核心安全服务器进行访问控制的主要部分，完成了访 问控制功能的主要工作。其中，策略管理模块实现了多策略的共存，核心安全服务器包括的 安全模型都由策略管理模块进行管理。安全上下文管理模块管理了核心安全服务器中使用 的安全上下文，集中管理安全上下文，提高了系统的安全性。策略数据库中保存的是平台所 支持的各种操作系统安全模型的安全规则，是核心安全服务器进行权限判定的重要依据， 核心安全服务器中的策略数据库通过读取二进制策略文件形成。核心安全服务器的决策缓 存模块和策略管理模块通过核心安全服务器接口与操作系统内核Hook层进行交互。
参见附图3，它是本实施例平台抽象层的结构示意图；对于实施访问控制，本实 施例考虑到的各个操作系统的不同点主要为以下几点操作集不同，内存对象不同和内核 API不同。操作集合的不同主要影响访问控制实施时需要监控不同的操作，如Windows系 统需要监控注册表操作，Li皿x需要监控文件系统挂载、卸载操作；内存对象不同主要影响 对内核对象打标签的方法以及位置不同，如Windows进程以PEPR0CESS表示，而Linux进 程以TaSk_Struct表示，这就影响了对系统主客体打标签的不同；由于核心安全服务器需 要运行于系统内核中，故而内核API的不同影响了核心安全服务器的实现，比如Windows、 Linux内核中有不同的锁操作API ;访问控制需要对整个系统的重要资源进行加固，但是各 个系统的重要资源是不同的，如Windows需要对注册表进行控制，Linux需要对各个虚拟文 件系统进行控制，这就需要核心安全服务器可以保护不同的资源。 正是针对这些不同点，本发明提出了与各操作系统无关的访问控制平台，加入了 一个平台抽象层，抽象出所要支持的各个操作系统的不同，使得核心安全服务器可以方便 的被实施到各个系统上。平台抽象层包含了内核API封装、内核对象抽象、内核操作集合抽 象等内容，使得核心安全服务器无需考虑各个平台的不同点，而只需要集中考虑访问控制机制的实现，方便了访问控制在各个平台的实施。 在本发明中，操作系统Hook层和核心安全服务器的安全上下文管理的实现方法 如下 由于访问控制需要对内核对象打标签，故而本实施例提供的操作系统访问控制平 台考虑到了各个系统实现的不同，包括系统是否开源，下面以Windows和Li皿x作为非开 源、开源操作系统的典型代表来说明本发明如何为不同的操作系统打标签。在本发明中， Context是安全标签(安全上下文)，SID则是Context的索引，SID与Context——对应， 其对应关系由核心安全服务器的安全上下文管理器维护。为了"应付"各个操作系统内核 对象的不同，本发明规定在操作系统Hook层维护内核对象至SID的映射，而在核心安全服 务器维护SID至Conetx的映射，参见附图4，它是本实施例安全标签设置的结构示意图；对 于Li皿x而言，2. 6以后的版本都支持LSM框架，LSM框架的实现就是通过为各个内核对象 添加安全域，所谓的安全域，实际上就是为安全模块打标签预留的位置。对于Windows而 言，是一个非开源操作系统，故而不能在各个内核对象上直接打标签，故而本发明采用了通 过为内核对象的句柄和SID做映射的方法给内核对象打标签。
下面通过一个访问控制的过程来说明平台无关的访问框架上具体流程。
设某个操作系统的一个进程其SID为l，想读一个SID为8的文件，操作系统Hook 层截获了这个请求，并将这个请求发给核心安全服务器。核心安全服务器先查看访问缓存， 看是否有在缓存中有相同请求，如果有，直接将结果返回给操作系统Hook层。如果缓存中 没有该请求，就查询核心安全服务器中的策略管理器，查看是否有进程1对文件8的读访问 权限，如果有则将该请求存放在缓存中，并返回允许。如果没有则返回不允许。
目前，本发明技术方案已在Windows、 Linux以及Rtems系统上实施，在Linux下， 操作系统Hook层使用了 LSM框架，成功加载了核心安全服务器，对Li皿x系统进行了安全 加固；在Windows下，本发明自行设计了 Windows访问控制实施框架，加载核心安全服务器， 控制Windows各个进程的行为；Rtems系统通过加载核心安全服务器提供了安全API，用户 可以使用安全API进行编程，控制进程的权限。
权利要求
一种操作系统的访问控制实现平台，其特征在于它包括操作系统Hook层、平台抽象层和核心安全服务器；所述的操作系统Hook层用于截获操作系统的请求，并提供给核心安全服务器进行安全判断；所述的平台抽象层包括平台支持的各种操作系统不同的操作集封装、内存对象封装和内核API封装，为核心安全服务器提供平台抽象；所述的核心安全服务器包括策略缓存模块、策略管理模块、安全上下文管理模块和策略数据库；所述的策略缓存模块用于保存最近发生的对系统操作的判定；所述的策略管理模块用于支持多种安全策略，并支持动态策略；所述的安全上下文管理模块用于管理安全上下文；所述的策略数据库中，保存平台支持的各种操作系统安全模型的安全规则，用于核心安全服务器对请求进行访问权限判定时提供依据。
2. —种操作系统的访问控制方法，其特征在于包括如下步骤(1) 操作系统Hook层将截获的请求发给核心安全服务器，由核心安全服务器的策略缓 存模块对该请求进行查询，判定在否有相同的请求存在于策略缓存模块中；如果有，直接返 回操作系统H(X)k层，执行该请求；如果没有，执行步骤(2);(2) 查询核心安全服务器中的策略管理模块，依据策略数据库中保存的平台所支持的 操作系统安全模型的安全规则，判定是否有该请求的访问权限，如果有，则将该请求存放在 缓存中，并返回操作系统Hook层，执行该请求；如果没有，则返回不允许，拒绝该请求。
全文摘要
本发明涉及一种操作系统的访问控制方法及其实现平台。该平台包括操作系统Hook层、平台抽象层和核心安全服务器。操作系统Hook层将截获的请求发给核心安全服务器，查询策略缓存模块，判定在否有相同的请求存在，如果有则执行，如果没有，查询策略管理模块，依据策略数据库中保存的操作系统安全模型的安全规则，判定是否有该请求的访问权限，如果有则将该请求存放在缓存中并执行，如果没有则拒绝。本发明提供一种可应用于多种操作系统的、灵活的访问控制平台，并提供统一的策略配置方法，能方便地将其在各个操作系统上实施。
文档编号G06F9/44GK101727555SQ20091023266
公开日2010年6月9日 申请日期2009年12月4日 优先权日2009年12月4日
发明者余艳玮, 杨峰, 胡大磊, 胡楠, 贾刚勇, 赵振西, 龚育昌 申请人:苏州昂信科技有限公司