一、提要

SROS 2 引入了几个安全属性，包括加密、身份验证和授权。授权是通过将前两个属性与访问控制模型相结合来获得的。这种模型通常被称为访问控制策略。策略充当与属性相关联的特权的高级抽象，然后可以将其转换为个人身份的低级权限，例如安全 DDS 网络中的特定 ROS 节点。

二、概念

在详细介绍访问控制的 SROS 2 策略设计之前，系统通过该策略限制主体访问对象的能力，重要的是要建立一些概念，这些概念在安全性方面对设计方法的形式化有用。在这种情况下，主体可能被认为是分布式数据总线上的参与者（例如计算图中的 ROS 节点），而对象可能是特定子系统的实例（例如 ROS 主题），并且可以访问被定义为对该对象采取行动的能力（例如发布或订阅）。

2.1 强制访问控制

强制访问控制 (MAC) 是指当且仅当存在允许给定主体访问资源的规则时才允许访问对象；强制性一词表示必须始终明确提供主体对对象的访问权的要求。最重要的是，与自主访问控制 (DAC) 相反，此类策略由一组授权规则强制执行，这些授权规则不能被主体意外或有意覆盖或修改。这也可以称为“默认拒绝”。

2.2 最小特权原则

最小特权原则 (PoLP) 要求在特定的抽象层中，每个主体都必须能够访问其合法目的所必需的资源。这也被称为最小特权原则或最小权限原则。应用 PoLP 不仅可以增强系统安全性，还可以简化部署并帮助提高系统稳定性。

2.3 特权分离

权限分离要求将主体的访问权限划分为多个部分，这些部分仅限于执行特定任务所需的特定权限。这用于减轻安全漏洞的潜在损害。因此，无法满足此要求的系统也可能无法满足 PoLP。

2.4 关注点分离

关注点分离 (SoC) 是将系统分成不同部分的设计原则，以便每个部分解决一个单独的关注点。在这种情况下，单独的问题可能是系统中如何管理加密与如何向主体授予授权。

三、标准

这里讨论了 SROS 2 策略和选择可扩展标记语言 (XML) 的设计标准。

3.1 验证

在解释任何用户配置输入（例如访问控制策略）之前，应应用数据验证以确保输入合规且格式正确。不正确的输入会影响大多数程序或工具的健全性，但防范一般畸形本身可能需要细致的验证逻辑。使用精确的模式对数据的描述进行形式化允许单独的程序断言输入是合规的，而无需跨实现复制验证逻辑。在 XML 中，这是使用 XSD 实现的；允许通过可扩展的标准定义而不是规范的实现来定义策略标记。

3.2 转型

对于可用性和通用性，可以使用特定领域的抽象来表达访问控制策略，例如基于 ROS 的主体和客体。然而，当应用于较低级别的传输和策略执行点时，此类抽象可能会转化为不同的表示。使用转换语言形式化此数据转换允许单独的程序进行转换，而无需跨实现复制转换逻辑。在 XML 中，这是使用 XSLT 实现的；通过简单地交换或扩展转换，可以轻松地将策略标记转换为各种传输。

3.3 作品

在制定访问控制策略时，许多主体可能共享基本访问权限。为避免可能加剧人为错误或其他差异的不必要重复，策略应具有足够的表达能力以保持 DRY。在 XML 中，这是使用 XInclude 实现的；允许策略标记轻松地包含或替换对跨单独策略或配置文件重复的特定配置文件和权限的外部引用。

四、架构

SROS 2 策略模式是用 XML 定义的。构成策略的元素和属性如下所述。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
               schemaLocation="http://www.w3.org/2001/03/xml.xsd" />


    <xs:element name="policy" type="Policy" />
    <xs:complexType name="Policy">
        <xs:sequence minOccurs="1" maxOccurs="1">
            <xs:element name="enclaves" type="Enclaves" />
        </xs:sequence>
        <xs:attribute name="version" type="xs:string" use="required" fixed="0.2.0"/>
    </xs:complexType>

    <xs:complexType name="Enclaves">
        <xs:sequence minOccurs="1" maxOccurs="unbounded">
            <xs:element name="enclave" type="Enclave" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="Enclave">
        <xs:sequence minOccurs="1" maxOccurs="unbounded">
            <xs:element name="profiles" type="Profiles" />
        </xs:sequence>
        <xs:attribute name="path" type="xs:string" use="required" />
    </xs:complexType>

    <xs:complexType name="Profiles">
        <xs:sequence minOccurs="1" maxOccurs="1">
            <xs:sequence minOccurs="1" maxOccurs="unbounded">
                <xs:element name="profile" type="Profile" />
            </xs:sequence>
            <xs:sequence minOccurs="0" maxOccurs="1">
                <xs:element name="metadata" type="xs:anyType" />
            </xs:sequence>
        </xs:sequence>
        <xs:attribute name="type" type="xs:string" use="optional" />
    </xs:complexType>

    <xs:complexType name="Profile">
        <xs:sequence minOccurs="0" maxOccurs="unbounded">
            <xs:choice minOccurs="1" maxOccurs="1">
                <xs:element name="topics" minOccurs="1" type="TopicExpressionList" />
                <xs:element name="services" minOccurs="1" type="ServicesExpressionList" />
                <xs:element name="actions" minOccurs="1" type="ActionsExpressionList" />
            </xs:choice>
        </xs:sequence>
        <xs:attribute name="ns" type="xs:string" use="required" />
        <xs:attribute name="node" type="xs:string" use="required" />
        <xs:attribute ref="xml:base" />
    </xs:complexType>

    <xs:complexType name="TopicExpressionList">
        <xs:sequence minOccurs="1" maxOccurs="unbounded">
            <xs:element name="topic" type="Expression" />
        </xs:sequence>
        <xs:attribute name="publish" type="RuleQualifier" use="optional" />
        <xs:attribute name="subscribe" type="RuleQualifier" use="optional" />
        <xs:attribute ref="xml:base" />
    </xs:complexType>

    <xs:complexType name="ServicesExpressionList">
        <xs:sequence minOccurs="1" maxOccurs="unbounded">
            <xs:element name="service" type="Expression" />
        </xs:sequence>
        <xs:attribute name="reply" type="RuleQualifier" use="optional" />
        <xs:attribute name="request" type="RuleQualifier" use="optional" />
        <xs:attribute ref="xml:base" />
    </xs:complexType>

    <xs:complexType name="ActionsExpressionList">
        <xs:sequence minOccurs="1" maxOccurs="unbounded">
            <xs:element name="action" type="Expression" />
        </xs:sequence>
        <xs:attribute name="call" type="RuleQualifier" use="optional" />
        <xs:attribute name="execute" type="RuleQualifier" use="optional" />
        <xs:attribute ref="xml:base" />
    </xs:complexType>

    <xs:simpleType name="Expression">
        <xs:restriction base="xs:string" />
    </xs:simpleType>

    <xs:simpleType name="RuleQualifier">
        <xs:restriction base="xs:string">
            <xs:enumeration value="ALLOW" />
            <xs:enumeration value="DENY" />
        </xs:restriction>
    </xs:simpleType>

</xs:schema>

4.1 标签解释

1） <policy> 标签

策略文件的根标签。每个策略文件必须只有一个 <policy> 标记。

属性：

version: 正在使用的架构版本的声明版本。
- 允许推进架构的未来修订
2）<enclaves> 标签

封装一系列独特的飞地。这种嵌套序列的方法允许将附加标签扩展到 <policy> 根。

3) <enclave> 标签
封装一组配置文件。这是特定于由关联属性确定的飞地。

属性：

路径：完全限定的飞地路径
鉴于可以将多个节点组合成一个进程，一个 enclave 用于包含所有相应节点的配置文件的集合。因此，一个飞地可以被认为是包含的配置文件的联合。请注意，enclave 内的配置文件的联合将导致任何配置文件的权限被拒绝，以取代每个配置文件的所有允许权限。例如。如果配置文件请求权限，但匹配的权限已被 enclave 中的另一个配置文件明确拒绝，则拒绝规则将优先。有关如何应用 MAC 的更多信息，请参阅 <profile> 标签部分。

4) <profiles>
封装一系列独特的配置文件和指定的元数据。这种嵌套序列的方法允许将附加标签扩展到 <enclave> 根，以及将特定元数据或约束与包含的配置文件元素相关联。

属性：

type：指定配置文件和元数据的传输类型

5)<profile> 标签
封装主题权限的集合。这特定于由关联属性确定的唯一节点实例。

属性：

ns：节点的命名空间
节点：节点的名称
根据 MAC，权限必须明确限定为允许的。此外，与许多其他 MAC 语言一样，虽然组合权限可能重叠，但任何特定的拒绝权限都会抑制任何类似适用的允许权限。也就是说，拒绝特权的优先级保守地取代了允许的特权，避免了 PoLP 中的潜在失误。这种扁平化权限的方法使用户能够提供对较大对象集的一般访问权限，同时撤销对较小敏感对象子集的访问权限。尽管随后阻止了限定符的递归，但随后简化了转换，防止了意外访问的可能性。

6) <metadata> 标签
封装任意元数据或约束。这可能包括适用于同级配置文件元素的传输特定权限详细信息。每个配置文件父元素只能有一个元数据元素。

属性：

被定义为, 考虑到桥接接口的用例，其中飞地的凭证可用于跨多个传输或传输特定域的互连，可能需要使用特定约束来限定某些配置文件序列，同时为每个飞地的单独配置文件多次这样做。这允许高级用户全面控制跨传输域的权限交叉，同时保持安全权限的准确模型保真度。鉴于桥接接口对安全性的敏感程度及其暴露的攻击面，桥接内的信息流控制必须保持形式上可验证，以确保安全和可靠的操作。

数据特权

权限被定义为对象访问的规则和权限的配置。由于对象可以按子系统类型进行分类，因此规则和相应的权限具有相同的结构。假设一个平均配置文件可能引用比规则数量更多的具有多个权限的唯一对象，则选择规则/权限/对象的后续层次结构以最小化冗长性。

rule types	permissions
actions	call, execute
services	reply, request
topics	publish, subscribe

每个子系统都与给定的规则类型相关联，而权限在其各自的规则标签中表示为属性。不需要此序列中规则的唯一性或排序，因为这是由转换模板来解释的。事实上，一个配置文件可能包含一组空的权限。当节点可能不需要子系统权限，但仍必须提供身份以用于 DDS 中的发现时，这特别有用。

每个规则都包含一系列权限适用的对象。对于某些安全传输，例如 Secure DDS，匹配表达式也可用于使用 globbing 模式进一步扩展范围，特别是 POSIX 标准中指定的 fnmatch 支持的那些。但是，在使用表达式匹配时应谨慎，如关注部分中进一步讨论的那样。

支持基本的 fnmatch 样式模式：

Pattern	Meaning
*	Matches everything
?	Matches any single character
[sequence]	Matches any character in sequence
[!sequence]	Matches any character not in sequence

7）<topics> 一组具有指定权限的 <topic> 标签。

属性：

publish：是否允许在这组主题上发布 IE。节点是否可以成为主题发布者有效值为“ALLOW”或“DENY”
subscribe：是否允许订阅这组主题 IE。节点是否可以成为主题订阅者有效值为“ALLOW”或“DENY”

8）<service> 标签一组具有指定权限的 <service> 标签。

属性：

request：是否允许请求服务 IE。节点是否可以是服务客户端有效值为“ALLOW”或“DENY”
reply：是否允许回复服务请求 IE。节点是否可以是服务服务器有效值为“ALLOW”或“DENY”

9）<actions> 一组具有指定权限的 <action> 标签。

属性：

call：是否允许调用动作 IE。节点是否可以是动作客户端有效值为“ALLOW”或“DENY”
execute：是否允许执行动作 IE。节点是否可以是动作服务器有效值为“ALLOW”或“DENY”

五、模板

要将 SROS 2 策略转换为目标访问控制传输的安全工件，可以使用 XSLT 模板来执行此级别的文档转换。这可能包括针对目标运输的任何数量的优化或调整。例如，针对 Secure DDS 的流水线阶段如下：

指定了具有 SROS 2 策略根的 XML 文档
使用 XInclude 完全扩展文档以引用外部元素
然后使用等效的模式版本验证扩展的文档
此时，文档树可能会或可能不会被修剪到特定的配置文件
然后使用转换模板对有效文档进行转译
对于每个配置文件，将匹配的 DDS 授权附加到权限文档中

特权和命名空间被重新映射到以 DDS 为中心的表示
结合具有匹配属性的权限以减少有效负载大小
修剪相同权限中的重复对象以减少有效负载大小
权限优先排序deny，使用DDS时遵守限定符的优先级
对象也按字母顺序排序以提高可读性和更改差异
备择方案

六、备择方案

本节列出了对提议的设计和考虑的替代方案的关注，包括不同的标记语言和策略格式。

6.1 YAML

YAML 是“YAML Ain't Markup Language”的递归首字母缩写词，最初在 SROS [1] 的第一个版本中用于指定访问控制策略。尽管 SROS 1 中使用的策略模型在语义上是等效的，但由于缺乏明确的元素属性，由于每个命名空间资源的权限重复，因此 YAML 格式使其非常冗长。对于 SROS 2，我们决定从 YAML 切换到 XML，原因有以下优点和缺点：

1）优点

人类可读：最小的线路噪声
YAML 的语法非常简单，专门针对人工可编辑的配置文件，使得手动读写变得简单。
数据模型：直观解释
YAML 具有非常简单的数据模型，使用键值对字典和列表形成树结构，使其非常易于使用。

2）缺点

可解析性：隐式类型转换
鉴于 YAML 是一种数据序列化语言，它可能会尝试在可能的情况下进行类型转换。然而，这并不总是具有预期的效果，并且可能导致意外行为。解析布尔值与字符串是歧义的显着例子。
口译员：验证和转换
尽管许多编程语言都支持 YAML，但 YAML 本身没有提供架构来强制执行文档结构。
必须对每个解释器实现重复验证，使其与所使用的编程语言无关。
类似地，将策略转换为传输安全工件的转换在实现之间不太通用。
可组合性：配置文件的重用
尽管 YAML 通过 Anchors、Aliases 和 Extensions 支持一定程度的可组合性，允许文档更加 DRY，但这些不会扩展到单独的文件或外部资源。
表现力：简洁的表示
鉴于 YAML 的继承数据模型，它的表达能力非常有限，需要冗长的文件结构或不直观的选项来实现类似的访问控制配置。

6.2 约定俗成

作为选择现有标记格式的替代方法，可以定义我们自己的正式语言，以使用自定义文件语法来表达 ROS 2 的访问控制权限。基于 MAC 的策略语言的示例包括 AppArmor 中使用的策略语言。尽管提供了简洁表达配置文件权限的灵活性，同时最大限度地减少了一般语法开销，但由于以下优点和缺点权衡的许多原因，这种方法没有被采用：

优点

表现力：简洁的表示完全控制语法和解释，允许针对 SROS 策略表示进行特定领域的优化。

缺点

口译员：验证和转换解析和解释自定义策略格式的规范和实现将被视为承担。必须对每个解释器实现重复验证，使其与所使用的编程语言无关。类似地，将策略转换为传输安全工件的转换在实现之间不太通用。正确性：政策依然健全跨多种编程语言维护和同步解析支持可能会影响策略的健全性。

6.3 通信装甲

ComArmor [2] 是现在 SROS 2 中使用的现有 XML ROS 2 策略格式的前身和灵感来源，它本身的灵感来自 AppArmor 的策略语言。 ComArmor 通过使用策略/配置文件/权限原语的嵌套树结构来促进组合。与 AppArmor 一样，它也支持配置文件的嵌套，即将子配置文件导入父配置文件。虽然这极大地扩展了嵌套导入的 sun-profile 层次结构的灵活性，但在将策略转换为安全传输工件时，它也增加了转译过程的复杂性。

为了在简单性和灵活性之间取得平衡，SROS 2 选择了单级配置文件的平面序列，从而允许策略格式作为更高级别策略语言的基础中间表示和构建工具，例如 XACML 或 Keymint，同时简洁地表达 ROS 概念以供一般使用。

七、被关注点

7.1 特权分离

ROS 2 子系统（例如主题、服务、动作和参数）最终必须映射到传输层接口，例如 DDS 主题，这可以充分执行所需的访问控制策略，以保护 ROS 应用层。但是，子系统映射和权限分离之间的任何怪异都会降低安全性。

例如，如果授予对以 /foo 开头的所有主题和服务的访问权限另外授予对以 /foo 开头的所有操作的访问权限，这将是权限分离的弱示例。当使用包含匹配模式的通配表达式（例如使用 fnmatch）时，这种情况可能会加剧，从而导致将无害且合理的策略不准确地应用于底层传输安全性。虽然 ROS 2 和 DDS 之间的这种特权分离仍然存在一周，但也许明智的做法是不鼓励将表达式匹配用于权限中的一般用途。

7.3 关注点分离

中间件传输，例如 DDS，提供了无数的功能和选项，例如用于 QoS 和安全性的功能和选项。从配置的角度决定要公开什么时，在其中许多之间划清界限可能会很棘手。尽管如此，ROS 2 的目标包括保持对运输的不可知论是合理的。尽管 SROS 2 策略格式的结构有意模仿 Secure DDS 的 permission.xml 格式，但在向与 ROS 2 数据流相切的表面非功能安全属性添加扩展时应小心，例如加密或发现治理。然而，如果 SROS 2 策略的预期目的成为跨传输的中间表示，并且随后是从更高级别的工具/表示自动生成的，或者可组合性得到充分保留，那么这个问题可能就不那么重要了。

参考资源

ROS 2 Access Control Policies

【ROS2原理16】SROS 2 访问控制策略