策略机PM（Policy Machine）不是去扩展现有的访问控制模型/架构，而是出于可复用、标准化的目的，将策略定义和执行中所包含的数学关系抽象出来形成通用关系集，并用这些关系来重新定义访问控制，其目标是为基于属性的策略（及组合）建立一种通用框架，以便仅通过一些简单的配置，就能支撑不同类型的策略的执行。可以将PM看作一种逻辑的机器，它包含了一组固定的关系（Relation）和功能（Function），其中关系可以通过一些管理操作（对策略表达进行修改）来进行配置，而功能则用于协助策略决策和策略（已按正确的形式表达）执行。

为了提供策略执行的灵活性，PM将策略与其实现机制分离开来，以完成策略与实现机制之间的解耦。PM面临的最大挑战是如何通过一个最小的基元集来定义和执行各种各样的、基于属性的安全策略。文中为策略定义和执行定义了一个可重用的集合，其中包含数据、关系和功能。PM中定义了3种基本的关系：指派（Assignment）、禁止（Prohibition）和职责（Obligation）。

01

系统架构

最简单的PM组成包括：PM客户端（PM Client），PM服务器（PM Server），PM数据库（PM Database）和一些资源服务器（Resource Server）。

图1 策略机系统架构

◆ PM服务器：包括PM数据库，策略决策点PDP，策略管理点PAP（Policy Administration Point），以及事件处理模块；

◆ PM客户端：包括PEP，API接口和能感知PM的应用系统。

图中，橙色部分的组件为可信组件，其他为非可信组件。

PM客户端或用户环境是PM在用户侧的运行环境，可以是操作系统、应用（如DBMS）、服务或者虚拟化环境。通常，PM用户通过PM客户端提供的GUI登入PM，验证成功后， PM在其客户端创建用户会话，为用户提供可访问资源（文件、邮件、工作项目等）的逻辑视图（称为个人客体系统POS，Personal Object System）。

另外，PM也可以允许用户请求特定的可访问资源。在用户会话中，用户可以创建或运行不同的PM进程来请求受PM保护的资源。PEP捕获资源访问请求后，申请PDP对该请求进行授权，客体的物理位置对PM服务器来说是可知的，但对客户端透明。如果PM服务器允许该请求，则在授权响应中携带客体的物理位置。接下来，PM客户端执行服务器的策略决策，允许或拒绝进程对客体的访问。PM客户端提供一组API，用于开发可感知PM的应用程序。

PDP接收PEP客户端发出的访问请求，计算授权决策，并向PEP返回结果。授权决策基于发起请求的用户/进程的（身份）标识、请求的操作、请求的资源/客体，以及存储在PM数据库中的许可和禁止关系（注：PM中用关系来描述规则）。本质上，请求被授权当且仅当存在指派（Assignment）关系（注：指授予权限），而且不存在禁止（Prohibition）关系（禁止用户/进程对客体操作）。

PM服务器的事件处理模块对职责（Obligation）关系（存储在PM数据库中）指定的事件进行响应处理，这些事件一般通过客户端在PM对象上的操作来触发。

最后，PAP用于管理（如配置策略）PM数据库。PM服务器提供一套命令集供客户端使用，以方便客户端调用其服务。PM数据库中包含了一组标准的数据和关系集，用来表示当前的策略配置，这些配置可以通过PAP来创建/修改，并最终由PDP用来计算策略决策。PM服务器的事件处理模块在响应某些事件时，也可能会对策略配置进行动态更新。

资源仓库/服务器用于存储被保护的客体对象，它们的位置对PM服务器是可见的，但对用户透明。PM客户端通过与资源服务器配合，来实现客体内容在资源仓库和用户环境之间的传输。资源服务器可能以PM客户端子模块的形式实现。

02

策略机

2.1

PM的基本元素

PM的基本元素包括授权用户（U），进程（P），操作 (Op)和客体（O）。用户是可以被唯一标识的实体，可以是人或“系统用户”。客体是由策略控制的系统实体，包括PM访问控制数据和关系，和特定环境相关实体，如文件、端口、剪贴板、电子邮件、数据库记录或字段等，系统的保护需求决定了客体的范围。操作是可以针对客体执行的动作，某些操作可能与PM的实现环境相关。例如，系统中的一般操作可分为读、写，但PM管理操作还包括PM数据及关系的创建、删除操作。

在计算机内，人需要通过进程来提交访问请求。

大多数访问控制模型把用户和进程统一起来，用术语“主体”代表它们，意为“主动的实体”。PM则认为它们是独立、但相关的实体（注：这种区分有助于PM的形式化定义和推导），其影响是更大的用户访问灵活性和透明度。进程是拥有内存的系统实体，以用户的立场来运行。进程的本质特点是它们发出访问请求，能够对自己的内存进行排他性的访问，也可以通过系统剪贴板或套接字与其他进程进行通信。一个用户可以与一个或多个进程关联，但一个进程通常只能与一个用户关联。文中用process_user(p)表示与进程p∈P关联的用户，<op,o>p代表一个进程访问请求，其中op∈OP，o∈O，p∈P。

为了提供策略属性的映射，引入策略类（Policy Class）的概念（注：一个策略类代表传统意义上的一条规则）。策略类的集合记为PC，用户、客体及其各自属性都属于某个策略类pc∈PC。显然，一个客体可能被多个策略类保护，一个用户也可能与多个策略类相关。

2.2

PM关系

PM定义了3种关系：

◆指派。用于表示或确定权限。（注：表示权限本身，也可以表示将权限授予某个实体，或者某个实体是否具有某个权限）

◆禁止。用于表示用户或进程的拒绝关系。

◆职责。用于定义事件-响应之间的关系。

其中，指派和禁止定义了用户和进程的访问状态，访问状态和职责一起就定义了PM中综合的策略状态。

（1）指派（Assignment）

PM权限具有3元组形式(u, op, o)，意为用户u能够对客体o执行op操作，其中u∈U，op∈OP，o∈O，(op, o)称为u的能力，(u, op)称为o的访问入口。与其他访问控制模式一样，PM权限也通过一些高级抽象来表达，包括用户属性UA（User Attribute）、客体属性OA（Object Attribute）、操作集（Operation Set）和策略类PC，以及用→表示的二元指派关系。

对于每个客体o∈O，单元素集合{o}是客体的一个属性（OA中的一个元素）。下文用o代表客体o或者具有客体属性意义的单元素集合{o}。注意，OA中可能包含其他的客体属性元素，从数学意义上来看，集合OA可能等于{o}，但文中所用的表示方式不同，简单起见，本文认为O ⊆ OA。

在PM中，所有的用户属性和客体属性不管是什么类型，都具有共同的语义。用户属性是一个多对多的关系，一方面定义了一组用户，另一方面定义了一组能力。这与“角色”的形式化定义是一致的。相同的语义也可以用来定义其他类型的属性，如利益共同体、组织单元、许可等级等。客体属性也是多对多的关系，一方面定义了一组客体，另一方面定义了一组访问入口。这种多对多关系可以从PM通用的指派关系中派生出来，定义如下：

一个用户可以被指派给一个或多个用户属性（u→ua）；

一个用户属性可以被指派给另一个用户属性（ua1→ua2）；

一个客体属性可以被指派给另一个客体属性（oa1→oa2），但前提是oa2不能是客体。

在不形成环结构的前提下，用户属性和客体属性的指派关系可以形成链式结构。用→*代表具有0或多个（下文表述为0个以上）指派关系的链，→+代表具有1或多个（下文表述为1个以上）指派关系的链。在指派关系的作用下，用户和客体的属性可以被看做容器。用户u被指派给属性ua（从容器的观点看，也可以说“用户u在属性ua中”）当且仅当u→+ua。同样，客体o被指派给属性oa（从容器的观点看，也可以说“客体o在属性oa中”）当且仅当o→*oa。

用户属性可以被指派给操作集（ua→ops），操作集也可以被指派给客体属性（ops→oa），其中ops∈OP。策略类中的指派关系ua→ops→oa定义了：ua中的所有用户能够对oa中的所有客体，执行ops中的所有操作。

在上述指派关系的定义下，用户属性指派ua1→+ua2有两层含义，其一是ua1的用户集（注：指具有ua1属性的用户集合）包含在ua2的用户集中，其二是ua1中的用户拥有与ua2相关的能力。与用户属性ua相关的能力是指那些通过ua→ops→oa获得的能力。类似的，客体属性的指派oa1→+oa2也有两层含义，其一是oa1的客体集（注：指具有oa1属性的客体集合）包含在oa2的客体集中，其二是oa1中的客体拥有与oa2相关的访问入口。与客体属性oa相关的能力是指那些通过ua→ops→oa获得的访问入口。

PM支持多种不同类型策略（如RBAC和MAC）的组合。但是，并不是每个用户都被每条策略所限制，用户属性和客体属性也不是与所有策略相关。用户/客体属性能够被指派给一个策略类，ua→pc或者oa→pc，其中pc∈PC。这种指派引出了用户、用户属性、客体及客体属性与策略类之间的映射。用户u或用户属性ua属于策略类pc的前提是，存在一个指派链（具有1个以上的指派关系），其起点是用户或用户属性，终点是策略类，即u→+pc或者ua→+pc，其中pc∈PC。同样，如果说客体o受控于策略类pc，或者客体属性oa属于或处于策略类pc中，则意味着存在一个指派链（具有1个以上的指派关系），其起点是客体或客体属性，终点是策略类，即o→+pc或者oa→+pc，其中pc∈PC。

在指派完成后，就可以来判断PM权限的存在。若u为用户，op为一个操作，o是一个客体，元组(u, op, o)代表一个PM权限，当且仅当对于控制o的每一个策略类pck，用户u在pck中有一个用户属性uak，客体o在pck中有一个客体属性oak，并且存在一个包含op（同时被指派给uak和oak）的操作集ops，如下图所示。

图2 （u,op,a）为PM权限

图中，带箭头的虚线表示“用户属性到操作集再到客体属性”的指派关系，避免与其他类型的指派关系混淆。

（2）禁止（Prohibition）

禁止有2种的类型：用户否决（User-deny）和进程否决（Process-deny）。文中用u_deny(u, ops, os)代表用户否决关系，其中u∈U，ops∈2OP，os∈2O，意为一个代表用户u的进程不能在客体集os中的客体上执行ops中的操作。用¬os代表os的补集，则u_deny(u, ops, ¬os) 意为一个代表用户u的进程只能在客体集os中的客体上执行ops中的操作。

同样，进程否决关系用p_deny(u, ops, os)表示，其中p∈P，ops∈2OP，os∈2O，意为进程p不能在客体集os中的客体上执行ops中的操作。则p_deny(u, ops, ¬os) 意为进程p只能在客体集os中的客体上执行ops中的操作。

用户否决和进程否决通常被称为禁止，因为它们代表着权限排除。

（3）职责（Obligation）

职责指的是事件模式/响应（Event Pattern/Response）关系，它定义了在什么条件下策略状态必须改变，以及如何改变。职责关系以(ep, r)对的形式表示，其含义为“当ep发生时，执行r”，其中ep是事件模式，r是一系列管理操作（称为响应）。

事件模式指定了一组条件，如果进程在客体上成功执行操作的上下文与这组条件匹配，那么与对应响应相关的管理操作必须立刻执行。环境上下文和事件模式可以定义一些参数，如进程的用户，所执行的操作，以及客体所处的容器（注：可能指客体属性）。在响应过程中，管理操作所需的参数信息可以事件上下文中提取到。

响应和职责由PM负责执行，严格来说，它们的执行不需要以权限为基础。尽管在其他的策略框架（如XACML和Ponder）中也用到“职责”的术语，但它们与本文的意义不同。

2.3

授权的实施方式

访问状态（授权）的实施通过中间调解的形式来实现，一个进程的访问请求<op,o>p被授权，当且仅当存在权限(u, op, o)，其中u=process_user(p)，并且能力(op, o)没有被u或p否决。

注意，如果PM权限(u, op, o)存在，并且p_deny(u, ops, os)也存在，其中u=process_user(p)，op∈ops，o∈os，用户u可能通过他的另一个进程p’（满足u=process_user(p’)）来执行能力(op, o)。但是如果u_deny(u, ops, os)和权限(u, op, o)同时存在，则u的进程和u均不能执行能力(op, o)。由此可见，否决优先是PM解决策略冲突的方式，并且在组合可能产生冲突的策略时，采用的是“与”操作逻辑。

03

策略配置的举例

展示了用PM来表达和执行不同类型的策略（包括RBAC、Chinese Wall、MAC、DAC）的方式，暂时用不到，略过。

04

总结

PM为访问控制提供一种通用的定义和执行框架，OASIS的XACML和Ponder策略定义语言也在该领域做了很多工作。XACML可以用于描述策略，以及访问控制决策（请求和响应）。XACML与PM都能支持策略组合中的权限合并，前者的缺点是策略定义和执行时，没有区分用户和进程，而且它的PDP是无状态的，这些都限制了它的策略表达能力。Ponder是一种面向对象的策略描述语言，主要用于编写分布式客体的安全和管理策略。

常见产品对多种不同策略的支持是通过分别部署不同的机制来实现的，例如同时支持MLS策略和知其所需策略，需要分别部署独立的机制。PM则采用了统一的机制来支持不同的策略。

Osborn et al.提出了一种用RBAC的不同配置来分别模拟MAC和DAC的方法。

Crampton对RBAC进行了扩展，通过黑名单机制来执行基于历史的SoD约束，在概念上与PM的限制类似。

本文以形式化方法，对定义用户、属性、客体、权限的概念，以及它们之间的关系。优点是描述非常准确，能够从数学角度看出各实体间的本质关系，但缺点是理解起来有点难，需要区分文中概念与我们通常理解的概念之间的区别。