一种用于实现系统状态感知安全策略的方法

技术领域

本发明涉及一种用于在基于计算机的系统上实现安全策略的方法和系统，尤其涉及一种在基于计算机的系统上实现强制性访问控制(Mandatory Access Control，MAC)的方法和系统。

背景技术

在计算机安全方面，强制访问控制(Mandatory Access Control，MAC)是指操作系统用于限制执行主体或发起方访问客体或目标或通常对客体或目标执行某种操作的能力的一种访问控制类型。在实践中，执行主体通常是进程或线程；客体是文件、目录、TCP/UDP端口、共享内存段、IO设备等形式。这些执行主体和客体每个都可以具有一组安全属性。每当执行主体尝试访问客体时，操作系统内核强制实施的授权规则会检查这些安全属性，并决定是否可以进行访问。任何此类尝试都会通过一组授权规则(也称为安全策略)进行测试，以确定是否允许进行此操作。

在MAC的情况下，安全策略由安全策略管理员集中控制，这意味着终端用户无法重写该策略，例如，对其它将受到限制的文件进行访问授权。相比之下，自由访问控制(discretionary access control，DAC)也控制执行主体访问客体的能力，但允许用户做出策略决策和/或分配安全属性。

过去，MAC与多级安全(multilevel security，MLS)和专用军事系统密切相关。在这种情况下，MAC意味着MLS系统的约束条件要求非常严格。然而，最近，MAC开始出现在军事或MLS之外的领域。Linux和Windows操作系统的最新实现允许管理员专注于网络攻击和恶意软件等问题，而非专注于MLS的严格要求或约束条件。然而，这些实现具有不同的缺点和限制。

例如，SELinux基于索引节点(inode)，这些索引节点唯一标识每个文件，并需要一个允许将SELinux元数据保存到文件的元数据结构中的文件系统。因此，SELinux具有相当复杂的配置语法，使得标准用户无法对SELinux进行访问。TOMOYO Linux基于声明请求访问的进程所需的行为和资源。此外，TOMOYO Linux是基于路径名的，而非基于元数据标签。其它例子包括：AppArmor，类似于SELinux，但基于类似于TOMOYO Linux的文件路径；以及Smack，类似于SELinux，但旨在使标准用户配置更简单。

通常，这些方案基于某些中间实体，这些中间实体提前知道请求访问的一方和允许访问(例如，访问文件)的一方。这样，可以创建允许或拒绝某个用户访问某种资源的静态规则。在双方本身在某些数据方面被认为是可信的或不可信的情况下，这种方法很有效。

然而，例如，当用户无意中通过欺骗或复杂系统中的错误泄露数据时，这种方法就存在不足。

如果考虑多个系统中的一个系统，例如计算机网络，这种方法就会变得更加复杂。如果考虑单独的系统，访问控制通常基于某种凭证，中间方需要决定是否允许服务请求。或者，可以存在一个防火墙，用来检查流量，作为单一控制点，并代表中间方(或和中间方一起)做出决策。然而，这些情况下的决策通常也是静态的。

事实上，大多数现有技术方案的目的是定义静态规则。在个别情况下，可以考虑系统状态，但这种保护是作为并行机制实施的，其中，检查系统状态独立于访问控制规则。当状态可能在状态评估和后续规则评估之间变化时，引入了可能的竞态条件。

此外，有些方法根据安全分类数据的性质具有一定的灵活性，例如，数据的分类可以根据谁有权访问数据动态更改。然而，这种方法仍然无法解决用户无意操作导致数据安全漏洞的问题。

发明内容

本发明的目的在于提供一种改进的用于在基于计算机的系统上实现强制访问控制(Mandatory Access Control，MAC)的方法和系统，以克服或至少减少上述问题。

上述和其它目的通过独立权利要求的特征实现。其它实现方式在从属权利要求、具体实施例和附图中显而易见。

根据第一方面，提供了一种用于在基于计算机的系统上实现强制访问控制(Mandatory Access Control，MAC)的方法，所述方法包括：

接收来自执行主体对所述基于计算机的系统的功能的请求；

获取关于所述基于计算机的系统的状态的实时输入数据；

根据所述实时输入数据，确定所述基于计算机的系统的当前状态；

至少部分地根据所述基于计算机的系统的所述当前状态，响应所述请求。

根据所提供的方法，可以将状态感知引入标准安全策略语言中。传统的强制访问控制系统无法定义应限制访问系统中的资源的、与系统状态相关的因素。引入状态感知可以写入系统状态感知规则，所述系统状态感知规则允许为所述规则指定与状态相关的条件，当所述规则应用于进程或系统之间的通信时，会考虑这些条件。这样，应用程序和系统可以允许进行交互，但当系统状态可能会损害数据的机密性时，可以暂时禁止通信。例如，当目标系统内存中包含敏感数据时，可以暂时阻止通信。或者，所述规则可以定义在什么系统状态下允许通信。

该方法可以根据系统的应用程序、威胁和能力进行扩展和伸缩。

当安全专家为大量设备定义规则时，该方法可以进一步为这些专家提供更多的工具。安全的重点可以从进程目标资源权限扩展到进程访问资源的整个系统状态。

此外，该方法也是用户友好的，因为在安全敏感应用程序仍然受到保护的同时，即使是单侧加载的应用程序也可以允许在系统中使用。

在第一方面的一种可能的实现方式中，所述功能包括以下至少一项：

访问所述基于计算机的系统的一个或多个客体；或

对所述基于计算机的系统的一个或多个客体执行操作。

在第一方面的一种可能的实现方式中，所述一个或多个客体包括以下至少一项：

在所述基于计算机的系统的存储设备上定义的文件系统的文件或目录；

在所述基于计算机的系统的内存设备上定义的分配的内存区域的一部分；

安装在所述基于计算机的系统上的应用程序；

在所述基于计算机的系统上运行的进程；

所述基于计算机的系统的通信端口；

所述基于计算机的系统的输入设备；或

所述基于计算机的系统的输出设备。

通过对上述可能客体范围实施该方法，特别是当考虑来自可信供应商以外的应用程序的安全风险时，可以提高例如Android等开放软件平台的安全性。

该方法可以进一步避免用户出错，例如，如果其它授权的应用程序正在从系统收集数据(如截屏或读取日志或访问其它此类源)，并且用户切换到安全敏感工作流，该工作流结合当前系统状态，可能会将信息间接泄露给未经授权的进程。

在第一方面的一种可能的实现方式中，所述方法还包括：为所述一个或多个客体中的至少一个定义保护级别，

其中，所述保护级别可以按照与所述至少一个客体关联的元数据的形式存储。

通过为客体定义保护级别，可以实施规则，这些规则不仅可以区分受保护客体和非受保护客体，而且还可以区分不同安全级别的受保护客体，并根据例如分配的执行主体的安全类别作出访问控制决策。按照关联的元数据的形式存储信息，可以方便快捷地访问用于作出该访问控制决策的相关信息。

在第一方面的一种可能的实现方式中，还根据所述一个或多个客体的所述保护级别，响应所述请求。

根据该实现方式，可以使用系统状态输入数据和有关保护级别的元数据的组合来作出更复杂的访问控制决策。

在第一方面的一种可能的实现方式中，所述执行主体为以下中的一项：

安装在所述基于计算机的系统上的应用程序；

在所述基于计算机的系统上运行的进程；或

包括多个设备的分布式系统的计算机设备。

根据该实现方式，当安全专家为分布式系统中连接的大量设备定义规则时，可以为这些专家提供更多的工具。这样，安全的重点可以从进程目标资源权限扩展到进程访问资源的整个系统状态。

在第一方面的一种可能的实现方式中，所述实时输入数据包括以下至少一项：

当前物理位置；

当前时间和日期；

在所述基于计算机的系统上当前安装的应用程序的列表；

在所述基于计算机的系统上当前运行的进程的列表，其中，所述进程可以包括显示信息的记录；

所述基于计算机的系统上当前登录的用户的列表；

所述基于计算机的系统的当前操作类别，其中，操作类别可以包括商业或个人用途；

在所述基于计算机的系统上当前要求的安全级别；

所述基于计算机的系统操作的可测量物理环境；

关于与所述基于计算机的系统操作的物理环境相关的网络连接状态的信息；

在所述基于计算机的系统的内存设备上定义的受保护段的状态。

通过上述可能的实时输入数据范围实现该方法，可以根据许多因素确定系统状态，并作出合理的访问控制决策。例如，当目标系统内存中包含敏感数据时，可以暂时阻止通信。或者，规则可以定义在什么系统状态下允许通信。在另一个示例中，当目标系统处于某个物理(高保密性)位置时，可以暂时阻止通信，并在系统离开这样的位置时允许通信。例如，在其它授权的应用程序通过截屏或键盘记录程序过程从系统收集数据的情况下，该实现方式尤其可以进一步避免用户出错。

在第一方面的一种可能的实现方式中，所述方法还包括：在接收所述请求之前，定义一组MAC规则，其中，所述MAC规则包括MAC条件，定义所述MAC规则可能需要在所述基于计算机的系统上的管理员权限，其中：

所述一组MAC规则可以存储在所述基于计算机的系统的存储设备上；

对所述请求的响应是至少部分地根据所述一组MAC规则进行的。

定义包括专用MAC条件的一组MAC规则使系统能够作出更复杂的决策，其中，系统状态可以按照非二进制方式考虑。将MAC规则的创建和编辑与管理员权限绑定，可以实现更严格的安全性，在这种严格的安全性的情况下，安全性级别较低的用户无法更改系统在不同系统状态下响应控制访问请求的方式。

在第一方面的一种可能的实现方式中，响应所述请求包括以下中的一项：

允许所述功能；

拒绝所述功能；

如果满足所述MAC条件中的一个或多个，则允许所述功能；或

在满足所述MAC条件中的一个或多个后，允许所述功能。

以一种可以按照非二进制方式考虑系统状态的方式定义包括专用MAC条件的一组MAC规则，可以定义更灵活的MAC方法，在该方法中，系统的响应在一个或多个预设条件未满足的情况下不会自动拒绝。这样，在设计系统安全策略时考虑到两次连续评估之间对系统状态的可能更改，在决定如何响应请求时，提供了进一步的可能性。

这增强了可用性，因为能够(由用户自己或代表用户)改变系统状态，执行操作，然后解除限制，而非告知用户禁止某项操作。

这样，这些规则能够指示访问监控器(如安全服务模块)在特定时间禁止启动某些应用程序。如果系统安装了白名单应用程序以外的应用程序，则防止某些应用程序一直运行，或者让用户将手机切换到只允许有限的一组应用程序运行和通信的模式中。

在第一方面的一种可能的实现方式中，所述方法还包括：

改变所述基于计算机的系统的所述当前状态；

至少部分地根据所述基于计算机的系统的改变后的当前状态，响应所述请求。

根据该实现方式，在允许通信之前可以改变系统状态。例如，在录制屏幕、音频或视频信号的情况下，该实现方式可以在允许屏幕内容更改或媒体播放之前停止录制过程。在远程服务的情况下，该实现方式可以请求在允许通信之前刷新目标系统内存的敏感区域。因此，与二进制允许/拒绝响应的一组静态规则相比，该额外的步骤使得MAC更灵活。这为防止用户出错提供了额外的保护，例如，如果其它授权的应用程序正在从系统收集数据(如截屏或读取日志或访问其它此类源)，并且用户切换到安全敏感工作流，该工作流结合当前系统状态，可能会将信息间接泄露给未经授权的进程。该方法也是用户友好的，因为该方法可以在具有某些限制条件的系统中允许访问敏感数据，而非拒绝来自，例如，单侧加载的应用程序的访问。因此，安全敏感应用程序仍然会受到保护。

在一个可能的实施例中，所述方法还包括：将所述系统状态恢复到其在改变之前的原始状态。

在第一方面的一种可能的实现方式中，改变所述基于计算机的系统的所述当前状态使得满足允许所述功能的一个或多个预定义条件。

该实现方式允许更改系统状态，以满足预定义的(MAC)条件，从而实现规则和系统状态之间的动态交互。

根据第二方面，提供了一种用于实现强制访问控制(Mandatory Access Control，MAC)的基于计算机的系统，其特征在于，所述系统至少包括：

数据采集模块(Data Collection Module，DCM)，用于获取关于所述基于计算机的系统的状态的实时输入数据；

处理器；

存储设备，用于存储指令，当所述处理器执行所述指令时，使得所述基于计算机的系统执行根据第一方面的任何一种可能的实现方式所述的方法。

在该系统中引入数据采集模块(Data Collection Module，DCM)，使得具有分配资源(例如，处理能力和内存)的特定硬件或软件专门用于采集有关所述基于计算机的系统状态的输入数据。具有独立的模块还提高了安全性，并使设置多个可能的输入通道变得更容易，这些通道彼此并行运行。

在第二方面的一种可能的实现方式中，所述系统还包括安全服务模块(SecurityService Module，SSM)，其中，所述SSM用于：

接收来自执行主体对所述基于计算机的系统的功能的请求；

从所述DCM接收关于所述基于计算机的系统的所述状态的所述实时输入数据，并且可选地，还接收关于所述功能的一个或多个客体的保护级别的元数据或包括MAC条件的一组MAC规则中的至少一个；

根据所述实时输入数据，确定所述基于计算机的系统的当前状态；

至少部分地根据所述基于计算机的系统的所述当前状态，并且可选地，部分地根据所述元数据或所述一组MAC规则中的至少一个，响应所述请求。

在该系统中引入安全服务模块(Security Service Module，SSM)，使得具有分配资源(例如，处理能力和内存)的特定硬件或软件专门用于执行评估不同输入数据和响应访问控制请求的任务。这使得通过额外的安全检查可以加固应用程序框架。所述SSM在某些方面可以与现有的SSM(平台安全系统的一部分、防火墙或其它此类单点控制点)类似。也就是说，所述SSM具有由规则组成的策略；通过受保护客体关联的元数据识别受保护客体；并在决策过程中应用规则。然而，传统MAC实现系统无法定义应限制访问系统上资源的与系统状态相关的因素，与此相比，这种方法将状态感知引入策略语言。

在第二方面的一种可能的实现方式中，所述基于计算机的系统在计算机设备上实现，其中：

所述系统还包括进程间通信(Inter Process Communication，IPC)模块，用于在所述设备上运行的应用程序之间交换数据；

所述SSM用于从所述IPC模块接收所述请求，并且还用于向所述IPC模块响应所述请求。

在单个设备上实现该系统，通过使进程间模块控制同一设备的资源和进程之间的通信，可以提高设备的安全性。这样，设备上的应用程序可以允许进行交互，但当系统状态可能会损害数据的机密性时，可以暂时禁止通信。

在第二方面的一种可能的实现方式中，所述基于计算机的系统实现为连接在数据网络中的多个计算机设备的分布式系统，其中：

所述系统还包括流量控制器(Traffic Controller，TC)模块，用于监控所述多个计算机设备之间的所有数据交换；

所述SSM用于从所述TC模块接收所述请求，并且还用于向所述TC模块响应所述请求。

在数据网络中连接的多个计算机设备的系统上实现该过程，通过使流量控制器模块控制目标系统的资源和进程，可以提高分布式系统的安全性。因此，流量控制器可以确保目标系统在允许使用数据流量之前处于安全状态。

根据下文描述的实施例，这些方面和其它方面将是显而易见的。

附图说明

在本发明的以下详细描述中，将参考附图中示出的示例性实施例更详细地解释各方面、实施例和实现方式，其中：

图1为根据第一方面的实施例的MAC实现方法的核心步骤的流程图。

图2为根据第一方面的另一个实施例定义客体的保护级别的流程图。

图3为根据第一方面的另一个实施例的MAC实现方法的流程图。

图4为根据第一方面的另一个实施例的可能类型的执行主体和客体的流程图。

图5为根据第一方面的另一个实施例的可能类型的输入数据的流程图。

图6为根据第一方面的另一个实施例定义并保存一组MAC规则的流程图。

图7示出了根据第一方面的另一个实施例的一组示例性MAC规则。

图8为根据第一方面的另一个实施例的响应接入请求(incoming request)的不同可能性的流程图。

图9为根据第二方面的一个实施例的基于计算机的系统的框图。

图10为根据第二方面的另一个实施例的基于计算机的系统的框图。

图11为根据第二方面的另一个实施例的计算机设备的组件的框图。

具体实施方式

图1为根据第一方面的实施例的MAC实现方法的核心步骤的流程图。

在第一个步骤101中，接收来自执行主体1对基于计算机的系统10的功能的请求。该方法的步骤涉及在基于计算机的系统10上实现强制访问控制(Mandatory AccessControl，MAC)，以控制执行主体对所述基于计算机的系统10的功能的访问。此功能可以是对客体2的访问，或通常对客体2执行某种操作。下面结合图4说明在此上下文中可能类型的客体和执行主体。

在下一个步骤102中，获取关于所述基于计算机的系统10的状态的实时输入数据3。下面结合图5说明在此上下文中可能类型的客体和执行主体。

在下一个步骤103中，根据所述实时输入数据3，确定所述基于计算机的系统10的当前状态。根据输入数据的类型，所述系统状态可以指许多不同的情况，例如，其它授权的应用程序是否正在从系统收集数据(如截屏或读取日志或访问其它此类源)。

在下一个步骤104中，至少部分地根据所述基于计算机的系统10的所述当前状态，生成所述请求的响应。这可能意味着，在上面的示例中，因为可能会间接向未经授权的进程泄露信息，所以只要正在进行数据收集，系统就会拒绝另一个应用程序对显示设备的访问。

图2为根据第一方面的另一个实施例定义客体的保护级别的流程图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在第一个步骤201中，定义一个或多个客体2中的至少一个的保护级别。在一个实施例中，该保护级别可以是简单的二进制属性，例如受保护或非受保护。在另一个实施例中，在保护范围内存在多个保护级别。在一个实施例中，除了根据所述实时输入数据3之外，还根据在本步骤中分配的保护级别响应所述基于计算机的系统10的功能的请求104。

在下一个可选的步骤202中，关于保护级别的信息按照与所述至少一个客体2关联的元数据4的形式存储。在一个实施例中，所述元数据4保存在所述基于计算机的系统10的存储设备13上，这使得在作出关于对所述请求104的响应的决策时，可以方便快捷地访问所述元数据4。

图3为根据第一方面的另一个实施例的两种可能的MAC实现方法的流程图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在图3所示的响应所述请求104之后的可能性的实施例中，所允许的功能为访问1041所述基于计算机的系统10的一个或多个客体2。在另一个实施例中，所请求和允许的功能为对所述基于计算机的系统10的一个或多个客体2执行操作1042。

图4为根据第一方面的另一个实施例的可能类型的执行主体和客体的流程图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在流程图的第一个步骤中，示出了可能类型的执行主体，例如，安装在所述基于计算机的系统10上的应用程序5、在所述基于计算机的系统10上运行的进程6、或包括多个设备的分布式系统22的计算机设备20。

在接下来的步骤102至104中，获得实时输入数据3，确定所述基于计算机的系统10的当前状态，并生成104对接入请求(incoming request)的响应。该响应可以是之后发回给执行主体的拒绝响应，或者允许对所示的客体的列表进行访问/操作。该客体为，例如，在所述基于计算机的系统10的存储设备13上定义的文件系统7的文件或目录、在所述基于计算机的系统10的内存设备11上定义的分配的内存区域8的一部分、安装在所述基于计算机的系统10上的应用程序5、在所述基于计算机的系统10上运行的进程6、所述基于计算机的系统10的通信端口16、所述基于计算机的系统10的输入设备14、或所述基于计算机的系统10的输出设备15。

图5为根据第一方面的另一个实施例的可能类型的输入数据的流程图。输入数据可以实时表示关于系统状态的不同类型的信息，如示例性象形图所示，例如，设备20的当前物理位置、当前时间和日期、在所述基于计算机的系统10上当前安装的应用程序5的列表、所述基于计算机的系统10上当前运行的进程6的列表，特别是是否存在记录任何显示信息的进程、所述基于计算机的系统10上当前登录的用户的列表、所述基于计算机的系统10的当前操作类别(可以包括，例如，商业或个人用途)、所述基于计算机的系统10上当前要求的安全级别、所述基于计算机的系统10的操作的任何可测量物理环境、关于与所述基于计算机的系统10的操作的物理环境相关的网络连接状态的信息、或在所述基于计算机的系统10的内存设备11上定义的受保护段的状态。

输入数据由数据采集模块(Data Collection Module，DCM)18采集，然后发送到安全服务模块(Security Service Module，SSM)19。所述安全服务模块19用于接收不同类型的进一步可能的输入信息，例如，关于功能的一个或多个客体2的保护级别的元数据4，或包括MAC条件(下文将更详细地描述)的一组MAC规则9；以及确定所述基于计算机的系统10的当前状态，并响应所述接入请求。

图6为根据第一方面的另一个实施例定义并保存一组MAC规则9的流程图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在第一个步骤中，在接收所述请求之前，定义一组MAC规则9。这些MAC规则9包括MAC条件，下面将详细描述MAC条件。

在一个实施例中，在下一个步骤中，定义所述MAC规则9需要所述基于计算机的系统10的管理员权限。这反过来可以实现更严格的安全性，在这种严格的安全性的情况下，安全性级别较低的用户无法更改系统在不同系统状态下响应控制访问请求的方式。

在下一个可选的步骤302中，所述一组MAC规则9存储302在所述基于计算机的系统10的存储设备13上。这使得所述安全服务模块(Security Service Module，SSM)19在响应所述接入请求时能够考虑MAC规则和条件。

图7示出了根据第一方面的另一个实施例的一组示例性MAC规则。

MAC规则根据规则语言定义，以与访问监控器(如安全服务模块19)配合，所述访问监控器除了实施规则外，还可以监控系统状态。此组合允许规则对规则的应用条件进行定义。规则与其它强制访问控制系统中使用的规则相似，但有一些例外或补充。

所述规则可以在规则表中定义，所述规则表中表示的列如下：

“决策”是指由访问监控器确定的控制访问响应。

“执行主体”可以指唯一的执行主体1(在一个特定的实现方式中，指的是应用程序5或进程6的数据包名，例如“com.huawei.ApplicationABC”)或一组执行主体1。可以有任意数量的组，并且这些组是由策略定义中与应用程序5关联的标签形成的。“任意”是硬编码通配符，在示例中，指的是一组所有可能的执行主体1。

同样的情况也适用于“客体”，其中，“客体”可以是一个组，也可以是进程间调用目标的唯一标识符。示例中的“敏感”是一组数据包，该组数据包在策略中具有与其关联的“敏感”标签。

在一个实施例中，可以在“敏感”标签中定义多个保护级别。

“子系统”和“操作”的分离允许定义适用于某些子系统中的“任意”操作的规则，或某些操作(例如，在示例性Android中，“意图”子系统中的“发送”操作)的更具体的规则。

“子系统参数”是策略语言的一个特性。“子系统参数”允许为子系统编写更细粒度的规则。例如，如果在“意图”子系统中存在“发送”操作，并且执行主体1正在向客体2发送数据，则允许根据与发送操作关联的数据类型或数据量编写规则。

“在满足……条件下，执行……”的工作原理如下：每次消息通过传递消息的系统或系统服务(例如Android中的Binder框架传递意图，或网络中的防火墙)时，该系统或系统服务都会查询访问监控器(如所述SSM 19)。在替代的实施例中，出于性能或其它原因优选访问监控器本身传递消息。然后，访问监控器根据关于与目标客体之间消息传递的规则，并在考虑系统状态之后，允许或拒绝向目标客体发送消息。如果满足了“在满足……条件下，执行……”条件，则通信可以继续。如果不满足，则阻止通信。“在满足……条件下，执行……”可以基于系统的测量，但也可以基于一天中的时间或其它此类因素，如上文参考图5所列举的。

“在满足……条件后，执行……”的工作原理类似，但“在满足……条件后，执行……”还可以指示访问监控器(至少)针对消息传递时长调整系统状态。因此，除了告知访问监控器检查系统状态外，规则还可以通知访问监控器合适的系统状态。这增强了可用性，因为能够代表用户改变系统状态，执行操作，然后解除限制，而非告知用户禁止某项操作。系统状态也可能恢复到执行受保护操作之前的状态。

在图7所示的示例性实施例中，定义MAC规则，以防止敏感应用程序的录屏。

前四行属于第一组MAC规则，这些MAC规则在启动敏感应用程序时通过向敏感应用程序发送意图来停止录屏进程。

该组包括两个MAC条件。定义为“ScreenRecording＝false”的“在满足……条件下，执行……”条件指的是仅在没有录屏进程运行的情况下允许启动敏感应用程序。定义为“action:StopScreenRecording,condition:ScreenRecording＝false”的附加“在满足……条件后，执行……”条件指的是在启动敏感应用程序时停止录屏进程，并且仅在未检测到录屏进程时允许启动敏感应用程序。

第五行和第六行属于第二组MAC规则，这些MAC规则在敏感应用程序可见时阻止启动录屏进程。

图8为根据第一方面的另一个实施例的响应接入请求的不同可能性的流程图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在步骤102中，SSM 19从DCM获取输入数据3，以及从存储设备13获取MAC规则9和(可选地)元数据4。

在定义了系统状态103之后，可以根据MAC条件和确定的系统状态以不同的替代方式响应请求104。

在一种可能的场景中，根据系统状态(和元数据4)检查规则，并且允许401或拒绝402该功能。

在另一种可能的场景中，根据系统状态(和元数据4)检查MAC规则9，并且在满足一个或多个MAC条件的情况下，拒绝402或允许403该功能。

在另一种可能的场景中，根据系统状态(和元数据4)检查MAC规则9，并且在满足一个或多个MAC条件后404(有延迟)，拒绝402或允许该功能。在一个实施例中，改变501所述基于计算机的系统10的状态，并且再次检查MAC规则9是否满足，以至少部分地基于所述基于计算机的系统10的修改后的状态确定对请求的响应502。

图9为根据第二方面的一个实施例的在计算机设备20上实现的基于计算机的系统10的框图。

所述系统10中称为数据采集模块(Data Collection Module，DCM)18的组件从一组预定义的源采集输入。所述设备20用于支持这种数据采集。这些输入数据可以是系统状态、一天中的时间、当前登录的用户以及需要包括在预定义的一组MAC规则9中的其它此类输入类别的测量。系统管理员定义这些MAC规则9，并且可以使用输入类别并设置这些类别的目标值作为规则的一部分。然后，可以有条件地应用规则的决策，并且该决策基于系统状态。

所述系统10还包括安全服务模块(Security Service Module，SSM)19，所有系统消息都通过该模块传递。该模块可以是作为所述系统10的补充或现有模块的扩展实现的新模块。所述SSM 19将MAC规则9以及来自所述DCM 18的输入数据3作为输入，所述输入数据3包括，例如，截屏状态、一天中的时间、安装的应用程序的列表以及可能与决定系统是否安全相关的任何其它附加源。所述SSM还可以将关于客体2的保护级别的元数据4作为输入。

所述系统10还包括进程间通信(Inter Process Communication，IPC)模块21，用于加载到所述计算机设备20上的内存11中的应用程序5a和5b之间交换数据。所述IPC模块21用于将来自一个应用程序5a的对另一个应用程序5b的功能的任何请求发送到所述SSM19。

在获得所有输入之后，所述SSM 19检查关于当前请求的规则，并允许或拒绝该请求，或者在满足某些条件时允许该请求，或者在满足某些条件后允许该请求。

图10为根据第二方面的另一个实施例的实现为连接在数据网络中的多个计算机设备20a、20b、20c的分布式系统22的基于计算机的系统10的框图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

在本实施例中，用于实现MAC的系统10被配置为作为执行主体1的源设备20a和作为客体2的目标设备20b之间的中间设备20c。

所述系统10中称为数据采集模块(Data Collection Module，DCM)18的组件从一组预定义的源采集输入。所述设备20a、20b、20c用于支持这种数据采集。这些输入数据可以是所述目标设备20b上的受保护内存段的状态、一天中的时间、在所述目标设备20b上当前登录的用户、在所述目标设备20b上运行的进程以及需要包括在预定义的一组MAC规则9中的其它此类输入类别。系统管理员定义这些MAC规则9，并且可以使用输入类别并设置这些类别的目标值作为规则的一部分。然后，可以有条件地应用规则的决策，并且该决策基于系统状态。

所述系统10还包括安全服务模块(Security Service Module，SSM)19，所有系统消息都通过该模块传递。该模块可以是作为所述系统10的补充或现有模块的扩展实现的新模块。所述SSM 19将MAC规则9以及来自所述DCM 18的输入数据3作为输入，所述输入数据3包括，例如，截屏状态、一天中的时间、安装的应用程序的列表以及可能与决定系统是否安全相关的任何其它附加源。所述SSM还可以将关于客体2的保护级别的元数据4作为输入。

所述系统10还包括流量控制器(Traffic Controller，TC)模块23，用于监控所述计算机设备20a、20b、20c之间的所有数据交换。所述TC模块23还用于将来自所述源设备20a上的一个应用程序5a的对所述目标设备20b上另一个应用程序5b的功能的任何请求发送到所述SSM 19。

在获得所有输入之后，所述SSM 19检查关于当前请求的规则，并允许或拒绝该请求，或者在满足某些条件时允许该请求，或者在满足某些条件后允许该请求。

图11为根据第二方面的另一个实施例的包括基于计算机的系统10的计算机设备20的组件的框图。为了简单起见，与本文先前描述或示出的相应步骤和特征相同或相似的步骤和特征使用与先前使用的相同的附图标记表示。

所述计算机设备20可以包括处理器(CPU)12，用于执行指令，所述指令使得所述基于计算机的系统10执行根据上述任何可能实施例的方法。

所述计算机设备20还可以包括存储介质(HDD)13(HDD)，用于存储输入数据3、元数据4、MAC规则9和将由所述CPU 12执行的基于软件的指令。

所述计算机设备20还可以包括存储器(RAM)11，用于(临时)存储应用程序5、5a、5b和进程6的数据。

所述计算机设备20还可以包括数据采集模块(Data Collection Module，DCM)18，用于获取关于所述基于计算机的系统10的状态的实时输入数据3。

所述计算机设备20还可以包括安全服务模块(Security Service Module，SSM)19，用于接收来自执行主体1的对所述基于计算机的系统10的功能的请求，从所述DCM 18接收关于所述基于计算机的系统10的状态的实时输入数据3，并且可选地，还接收关于所述功能的一个或多个客体2的保护级别的元数据4或包括MAC条件的一组MAC规则9中的至少一个；根据所述实时输入数据3，确定所述基于计算机的系统10的当前状态；至少部分地根据所述基于计算机的系统10的所述当前状态，并且可选地，部分地根据所述元数据4或所述一组MAC规则9中的至少一个，响应所述请求。

所述计算机设备20还可以包括IPC模块21，用于在所述计算机设备20上运行的应用程序5之间交换数据。或者，如果所述基于计算机的系统10实现为连接在数据网络中的多个计算机设备20a、20b、20c的分布式系统22，则所述计算机设备可以包括流量控制器(Traffic Controller，TC)模块23，用于监控所述多个计算机设备20a、20b、20c之间的所有数据交换。

所述计算机设备20还可以包括用于接收来自用户的输入的输入设备(IN)14、用于向用户传送信息的电子显示器等输出设备(OUT)15以及用于直接或通过计算机网络间接与外部设备通信的通信接口(COMM)16。

所述计算机设备20内的上述提到的硬件元件之间可以通过内部总线17连接，所述硬件元件用于进行数据通信和处理操作。

本文结合各种实施例描述了各种方面和实现方式。但本领域技术人员通过所请求保护的主题，研究附图、本发明以及所附的权利要求，能够理解并获得公开实施例的其它变体。在权利要求中，术语“包括”不排除其它元件或步骤，且“一”并不排除复数的可能。单个处理器或其它单元可以满足权利要求中所述的若干项的功能。在仅凭某些措施在相互不同的从属权利要求中描述这个事实并不意味着这些措施的结合不能在有利的实现方式中使用。计算机程序可以存储/分配到合适的介质中，例如与其它硬件一起或者作为其它硬件的一部分提供的光存储介质或者固态介质，还可以按照其它形式，例如，通过因特网或者其它有线或无线电信系统的形式分配。

权利要求书中所用的附图标记不应解释为对范围的限制。