5 篇博文 含有标签「权限」

4.1 概念​

Attribute Based Access Control (基于属性的访问控制 )，简称ABAC, 是一种根据主体属性、对象属性、环境条件，使用预先定义的策略(Policy)对操作对象进行验证的访问控制方式。ABAC是对RBAC的改进，用于更细粒度更灵活的访问控制，NIST于2015年发表论文对ABAC标准进行了定义。

主体是指用户或组织。以用户为例，用户的属性是指用户的学历、性别、年龄等。

对象是系统资源，如⽂件、设备、程序、网络等。以文件为例，对象的属性是指文件的名称、大小、类型、拥有者等。

操作是主体请求对对象执⾏的功能。例如文件操作，包括对文件的读、写、编辑、删除、复制、执⾏和修改等。

策略(Policy)是一组访问规则。用于定义主体对对象可以执行某种操作。例如：小明对文件test.txt可以执行读操作，这里小明是主体，test.txt是对象，读是操作。

4.2 工作原理​

下图展示了基于ABAC访问控制机制下，主体访问对象的工作原理：

1. 主体请求访问对象。
2. ABAC访问控制机制根据主体属性、对象属性、环境参数、操作、策略对该请求进行授权验证。
3. 如果验证通过，则可以访问对象。

在现实世界的例子：

”我作为一名爸爸，希望授权5岁的儿子，在电视上看1个小时的《超级飞侠》动画片。“

在这个例子中，“爸爸”相当于系统管理员，可以对动画片资源设定访问权限。

主体是“儿子”，主体的属性是：5岁（属年龄）。

对象是“文件“，对象的属性是：超级飞侠（属名称），动画片（属类型）。

环境属性是：电视(属设备)、1个小时（属时间范围）。

假如当前系统的策略定义格式为：allow {主体[属性]} {对象[属性]} {环境}{操作}，则对这个例子的策略定义为：

allow {儿子[年龄=5岁]} {文件[类型=动画片 and 名称=超级飞侠]} {环境[设备=电视 and 时间=10:00~11:00]} {操作[读]}

在满足以上条件后，在儿子观看《超级飞侠》时，ABAC访问控制机制就可以根据主体属性、对象属性、环境条件，使用爸爸预先定义的策略(Policy)对这次访问进行验证，如果验证结果通过，就可以观看。

4.3 与RBAC比较​

RBAC与ABAC之间的主要区别在于授予访问权限的方式。 RBAC按照角色授予访问权限，ABAC可以根据主体、对象、环境、操作类型等属性确定访问权限。

RBAC 模型构建起来更加简单，对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC模型。对于大型组织，RBCA模型需要维护大量的角色和授权关系，从⽽导致通常所说的“⻆⾊爆炸”。且RBCA无法做到对对象细粒度地授权。

参考链接​

ABAC定义和注意事项指南

权限管理系统RBAC和ABAC

3.1 概念​

Role-Based Access Control (基于角色的访问控制)，简称RBAC。是一种基于角色并使用角色中预先定义的策略(Policy)对主体操作对象进行验证的访问控制方式。NIST于1992年发表论文对RBAC标准进行了定义。

什么是角色？在企业中访问控制的范围通常取决于员工所扮演的角色，角色中包含企业已确认的职责、责任和资格的规范，例如：软件公司中的角色包括工程师、设计师、商务人员等，每一种角色根据其包含的职责通常有不同的访问范围。

主体是指用户或组织。

对象是系统资源，如⽂件、设备、程序、网络等。

操作是主体请求对对象执⾏的功能。例如文件操作，包括对文件的读、写、编辑、删除、复制、执⾏和修改等。

策略(Policy)是一组访问规则。用于定义角色对对象可以执行某种操作。例如策略：允许商务人员对文件"客户资料.xlsx"执行读操作，这里商务人员是一个角色，"客户资料.xlsx"是对象，读是操作。

3.2 工作原理​

下图展示了基于RBAC访问控制机制下，主体（小明）访问对象的工作原理：

1. 主体请求访问对象。

2. RBAC访问控制机制首先获取主体的角色，然后根据角色中的策略对该请求进行授权验证。

3. 如果验证通过，则可以访问对象。

在现实世界的例子：

”我作为一名管理员，希望授权小明(商务人员)，读取文件“客户资料.xlsx”。

访问主体是“小明”，主体的角色是商务人员。

对象是 “客户资料.xlsx”。

实现方式

1. 新建一个角色为“商务人员”。

2. 假如角色的策略定义格式为：allow {角色} {对象} {操作}，则定义以下策略：

   allow {商务人员} {客户资料.xlsx} {读取}
   

3. 设置“小明”的角色为“商务人员角色”。

在满足以上条件后，当“小明” 读取文件“客户资料.xlsx”时，RBAC访问控制机制就可以根据主体角色，使用管理员预先定义的策略(Policy)对这次访问进行验证，如果验证结果通过，就可以读取。对于其他新增商务人员的授权也只需要设置角色为“商务人员”即可访问商务人员对应的文件，如果有人员离职，也只需要将离职人员移除角色即可，这样就通过角色实现了人员和访问资源的解耦，提高了权限配置的效率。

3.2 数学描述​

为了阐明概念，我们对RBAC给出⼀个简单的数学描述。这里的主体s指“用户”，例如"小明"。事务t是指操作+对象，例如：读取文件“客户资料.xlsx”。

主体s的活动角色，活动角色是主体当前正在使用的角色：

主体s的授权角色，每个主体可以授权多个角色：

每个⻆⾊都可以被授权执⾏⼀个或多个事务：

主体执⾏事务，当且仅当主体(if and only if)主体s可以在当前时间执⾏事务t ，函数exec(s,t)为真，否则为假：

三个基本原则

数学符号解释

∀ 任意，相当于every。当∀后面跟有以x为变量的公式时，写作(∀x)，读作“任意x”。例如，(∀a)a≥6表示所有的a都不小于6。

⇒ 推出，A⇒B意味着如果A为真，则B也为真；如果A为假，则对B没有任何影响。

≠ 不等于。

Ø[fai] 空集， 指不含任何元素的集合。

⊆ 包含于，表示一个集合中的元素全部是另一个集合里的元素。

1. ⻆⾊分配：只有当主体选择或分配了⻆⾊时，主体才能执⾏事务。系统上的所有其他⽤⼾活动都是通过事务进⾏的，因此所有活跃⽤⼾都需要有⼀些活跃的⻆⾊。

   公式解释：执行事务成功 only if 活动角色不为空。

2. ⻆⾊授权：⼀个主体的活动⻆⾊一定是已授权的角色：

   公式解释：活动角色是已授权角色的子集。

   $$∀s:subject,(AR(s) ⊆ RA(s))$$

3. 事务授权：只有当事务被授权为主体的活动⻆⾊时，主体才能执⾏该事务：

   公式解释：执行事务成功 only if 事务包含已授权的活动角色。

   $$∀s:subject,t : tran, (exec(s,t) ⇒ t ∈TA(AR(s))).$$

对于 (1) 和 (2)确保⽤⼾只能执⾏他们被授权的事务。请注意，因为条件是“only if”，所以允许对事务执⾏施加额外限制的可能性。也就是说，不能仅仅因为它在TA(AR(s))中就保证事务是可执⾏的，TA(AR(s))是主体的活动⻆⾊可以执⾏的事务。例如，主管⻆⾊的实习⽣可能被分配“主管”⻆⾊，但对其⽤⼾⻆⾊施加了限制，将可访问的事务限制为主管⻆⾊通常允许的事务的⼦集。

4. 强制控制⽤⼾必须通过某种验证函数访问对象的模式：

   公式解释：执行事务成功 only if access(AR(s),f,o, x)

   access(AR(s),f,o, x) 表示是否允许活动⻆⾊中的主体使⽤函数f对对象o执行x操作 ，其中x指某些模式集，例如：读r、写w、执行x。

例如，在医院环境中，使⽤这条策略可能是合适的。可以为医⽣提供对处⽅⽂件的读/写权限，⽽药剂师只有读权限。 （回想⼀下，单独使⽤前4个原则需要绑定事务中的f和o，并且只控制对事务的访问。）使⽤ (4)可能有助于强制执⾏机密性要求。

RBAC 的另⼀个⽤途是⽀持完整性。完整性已以多种⽅式定义，但完整性的⼀个⽅⾯要求数据和流程只能由授权⽤⼾以授权⽅式进⾏修改。对于许多实际系统来说，这似乎是⼀个合理的安全⽬标，并且 RBAC 应该适⽤于此类系统。

通常，确定数据是否仅以授权⽅式修改的问题可能与进⾏修改的事务⼀样复杂。出于这个原 因，实际的⽅法是对事务进⾏认证和信任。如果必须信任事务，则可以将访问控制直接合并到每个事务中。

要求系统通过 (4) 中使⽤的访问函数来控制事务程序对对象的访问可能是⼀种有⽤的冗余形式，但它可能会涉及⼤量开销，从⽽在执⾏完整性要求时获得有限的好处。

因此，在 RBAC 中包含对对象访问控制功能的事务将在某些应⽤程序中有⽤。

3.2 与DAC比较​

在多数企业中，员工通常并不拥有其允许访问文件的“所有权”，而是仅拥有基于自己的角色的文件的“访问控制权”。

DAC模型允许系统用户访问拥有权限的任意文件，并能够将其现有的访问权限直接(或者间接)传递给任何其他用户，而无需系统管理员干预，这是不安全的。

RBAC模型的系统⽤⼾不能⾃⾏决定将权限传递给其他⽤⼾，这是 RBAC 和 DAC 之间的根本区别。

3.3 使⽤ RBAC 集中管理安全性​

RBAC 是灵活的，因为它可以在策略和结构⽅⾯具有组织特征。 RBAC 最⼤的优点之⼀是它⽀持的管理功能。

⼀旦⻆⾊的事务在系统中建⽴，这些事务往往会保持相对恒定或随时间缓慢变化。管理任务包括授予和 撤销系统内指定命名⻆⾊集的成员资格。

当新⼈进⼊组织时，管理员只需将成员资格授予现有⻆⾊。当⼀个⼈在组织内的职能发⽣变化时，可以 轻松删除其现有⻆⾊的⽤⼾成员资格并授予新⻆⾊。最后，当⼀个⼈离开组织时，所有⻆⾊的所有成员资格都将被删除。对于经历⼤量⼈员流动的组织，RBAC是唯⼀合乎逻辑的选择。

此外，⻆⾊可以由多个子⻆⾊组成。例如，医院里有 治疗师、实习生 和 医生⻆⾊。图2描述了这种关系的 ⼀个⽰例。

通过授予成员医⽣⻆⾊，这意味着可以访问实习⽣和治疗师定义的所有事务，以及医⽣的事务。通过授予成员实习⽣⻆⾊，意味着实习⽣和治疗师⽽不是医⽣的事务。但是，通过授予成员治疗师⻆⾊，则仅允许访问治疗师⻆⾊下允许的资源。

3.4 最⼩特权原则​

最⼩特权原则已被描述为对于满⾜完整性⽬标很重要。最⼩权限原则要求⽤⼾获得的权限不超过执⾏⼯作所需的权限。确保最低权限需要确定⽤⼾的⼯作是什么，确定执⾏该⼯作所需的最低权限集，并将⽤⼾限制在具有这些权限的域中。

3.5 职责分离​

系统管理员可以使⽤ RBAC 机制来执⾏职责分离策略。职责分离在阻⽌欺诈⽅⾯被认为是有 价值的，因为如果存在各种与⼯作相关的能⼒之间的协作机会，就会发⽣欺诈。职责分离要求对于特定的事务集，不允许单个个⼈执⾏该集中的所有事务。最常⽤的⽰例是启动⽀付和授权⽀付所需的单独事务。任何⼀个⼈都不应该能够同时执⾏这两项事务。

职责分离是实际系统中的⼀个重要考虑因素。在实际情况下，只有某些事务需要根据职责分离要求进⾏限制。例如，我们希望“授权⽀付”的事务受到限制，但“向管理员提交建议”的事务不会受到限制。

职责分离可以是静态的或动态的。可以简单地通过将个⼈分配给⻆⾊并将事务分配给⻆⾊来确定是否符合静态分离要求。更困难的情况是动态职责分离，只有在系统运⾏期间才能确定是否符合要求。动态职责分离背后的⽬标是在操作中提供更⼤的灵活性。考虑发起和授权付款的情况。静态策略可能要求任何可以作为⽀付发起⼈的个⼈也不能作为⽀付授权⼈。这可以通过确保执⾏发起者⻆⾊的⼈也可以执⾏授权者⻆⾊来实现。这样的策略对于商业⽤途来说可能过于僵化，使得安全成本⼤于没有安全的预期损失。

3.6 总结和结论​

在⼯业界和⺠间政府的许多组织中，最终⽤⼾并不“拥有”他们被允许访问的信息。对于这些组织，公司或机构是系统对象的实际“所有者”，DAC可能不合适。基于⻆⾊的访问控制 (RBAC) 是⼀种⾮⾃主访问控制机制，它允许并促进对组织特定安全策略的集中管理。

访问控制决策通常基于个⼈⽤⼾作为组织的⼀部分所承担的⻆⾊。⻆⾊指定⼀个⽤⼾或⼀组⽤⼾可以在组织的上下⽂中执⾏的⼀组事务。 RBAC 提供了⼀种命名和描述个⼈与权利之间关系的⽅法，提供了⼀种满⾜许多商业和⺠间政府组织的安全处理需求的⽅法。

已经描述了各种形式的基于⻆⾊的访问控制，其中⼀些在当今的商业系统中使⽤，但是没有普遍接受的 定义或包含 RBAC 的正式标准。因此，这些系统的评估和测试程序尚未像符合可信计算机安全评估标准 的系统那样建⽴。本⽂提出的 RBAC 的要求和访问控制策略可以作为基于⽤⼾⻆ ⾊的访问控制的通⽤定义的基础。

参考链接​

基于角色的访问控制(RBAC) 原始论文

克拉克-威尔逊模型

RBAC就像它本来的样子

Mandatory Access Control( 强制访问控制 )，简称MAC, 是在计算机安全领域中的一种访问控制类型，操作系统通过这种访问控制来限制主体对对象执行操作的能力。在操作系统的情况下，主体通常是进程；对象是诸如文件、目录、网络端口、IO 设备等。主体和对象各有一组安全标签。每当主体尝试访问对象时，操作系统内核强制执行的授权策略会检查这些安全标签并决定是否可以进行访问。任何主体对任何对象的任何操作都会根据一组授权策略进行简称，以确定该操作是否被允许。

MAC的成熟实践主要有Linux的SELinux和Windows的MIC，以下我们以SELinux为参考，讲解MAC模型。

2.1 SELinux​

2.1.1 什么是SELinux​

安全增强型 Linux（SELinux）是一种采用安全架构的Linux 系统，它能够让管理员更好地管控哪些人可以访问系统。它最初是作为 Linux 内核的一系列补丁，由美国国家安全局（NSA）利用 Linux 安全模块（LSM）开发而成。

SELinux 于 2000 年发布到开源社区，并于 2003 年集成到上游 Linux 内核中。

2.1.2 为什么需要SELinux​

回顾第1章我们介绍的权限三要素为：主体对哪个对象拥有什么访问策略。

在DAC模型中，对资源访问的主体是用户，没有对进程的行为做任何限制，假如当前用户是root组，该用户启动了Apache+MySQL的服务端程序对外提供WEB服务，如果黑客可以通过漏洞成功劫持该进程，则黑客可以对计算机中所有资源做任意操作，比如直接修改MySQL服务中的各种业务数据，这是非常严重的后果。

在SELinux中，对资源访问的主体为进程，在上面的例子中，我们可以将Apache进程的访问资源限定在指定的数据目录如 /data/apache中，这样即使黑客劫持Apache进程，即使root用户，也只能访问 /data/apache这个目录，没有权限访问MySQL的数据，无法破坏业务数据，因此提高了系统的整体安全性。

2.2.3 SELinux 如何工作​

SELinux 为系统上的应用程序、进程和文件定义了访问控制。它使用安全策略（一组策略告诉 SELinux 什么可以访问或不可以访问）来强制执行策略允许的访问。

当称为主体的应用程序或进程请求访问对象（如文件）时，SELinux 会检查访问向量缓存，简称AVC(Access Vector Cache)，其中缓存了主体和对象的权限决策。如果 SELinux 无法根据缓存的权限做出访问决策，它会将请求发送到安全服务器。安全服务器检查应用程序或进程和文件的安全上下文,从 SELinux 策略数据库应用安全上下文，然后授予或拒绝许可，决策作出后，会加入到AVC中。

SELinux 是一个标签系统，每个进程、文件/目录对象都有一个标签，甚至网络端口、设备和可能的主机名也有分配标签。我们编写策略来控制进程标签对对象标签（如文件）的访问，称之为策略(policy)。内核(kernel)负责执行策略，而这种强制执行就称为强制访问控制，简称MAC(Mandatory Access Control)。

2.2 概念​

SeLinux的MAC实施由三个相对独立的子模型组成：分别为TE、MLS、MCS，我将详细介绍这三种模型。在学习下面三种模型之前，我们需要明确两个基本语言概念：类型(Type)和类别(Category )的区别？

汉语词典的解释：

类型 是由各种具有共同特征的事物或现象所形成的种类。

类别 是按种类的不同而做出的区别。

类型可以通过共同特征来准确识别对象，是客观存在的事实，是严谨的。而类别是一组主观认为的相似属性的对象，并不一定是客观事实，不严谨。

举个例子

1. 路边有3只动物，我将它们的类型定义为猫，则它们必须是猫，是严谨的客观事实，所有人都能根据类型识别出它们到底是不是猫。还是这3只动物，我将它的类别划分为“活泼的”和“安静的”，但这个类别只是我主观观察的结果，是随意的，不一定是事实。

2. 文件夹下有10个文件，我将它们的类型定义为图片，并将它们的类别划分为“自然风光”和“海洋世界”。这里的图片类型是客观事实，划分的图片类别是主观定义。

因此当你需要对一些对象进行分类时，可以优先使用类型划分，这样比较准确，然后再考虑使用类别划分。

2.3 TE 模型​

SELinux 主要模型称为类型强制，简称TE (Type enforcement) 。基本上，这意味着我们根据进程的类型定义进程的标签，并根据其类型定义文件系统对象的标签。

举个例子

以下充满活力和趣味的CAT/DOG系列示例来自RedHat工程师Daniel J Walsh和交互设计师Máirín Duffy，本文作者进行了一些中国化处理，感谢原文作者的优秀创作。

注：狗粮盘子上的字母Fido[fai.dow]是一只意大利流浪狗的名字，于1941年被一位名叫索里亚尼的砖窑工人收留，后来的两年间，Fido每个工作日都在公交站接送索里亚尼上下班。1943年第二次世界大战间，有一天意大利遭到盟军轰炸，索里亚尼阵亡，那天晚上，Fido 像往常一样出现在公交车站，但没有看到索里亚尼下车，Fido 后来回家了。但此后的十四年直到它去世的那一天，它每天都去车站，等着索里亚尼下车。

有一个叫做"宠物餐厅"的SELinux操作系统，有CAT和DOG两种动物，我们将CAT和DOG定义为进程类型，这是主体类型。

我们有它们想要与之交互的对象，称之为食物。为食物添加类型，CAT_CHOWN和DOG_CHOW，这是对象类型。

作为一名策略制定者，我会说猫有权限吃CAT_CHOWN食物，狗有权限吃DOG_CHOW食物。

在 SELinux 中，我们会在策略中编写此策略:

allow CAT CAT_CHOWN eat;

allow DOG DOG_CHOW eat;

使用这些策略，Linux内核将允许CAT进程吃标记类型为CAT_CHOWN的食物，而狗吃标记类型为DOG_CHOW的食物。

但是在 SELinux 系统中，默认情况下没有设定权限的所有访问对象的行为都会被拒绝。这意味着如果 DOG进程试图吃掉CAT_CHOWN ，内核会阻止它。

同样，CAT也不允许吃DOG_CHOW。

同理，在人类的网上银行生产环境中的例子：

我们将 Apache 进程标记为httpd_t类型 ，并将 Apache 的访问数据内容标记为httpd_sys_content_rw_t类型。假设我们将储蓄卡数据存储在标记为msyqld_data_t的 MySQL 数据库中。如果 Apache 进程被黑客入侵，黑客可以控制httpd_t 进程并被允许读写内容httpd_sys_content_rw_t。但是即使进程以 root 身份运行，黑客也不会被允许读取信用卡数据 ( mysqld_data_t )。

在这种情况下，SELinux 已经减轻了入侵带来的后果，提高了安全性。

2.4 MCS 模型​

多类别模型，简称MCS (Multi-Category Security) ，是一种访问控制机制，是对TE的增强。用户使用类别分别标记进程和文件后，进程只能访问与其类别相同的的文件。

MCS用于进一步限制自由访问控制( DAC ) 和类型强制( TE ) 逻辑，假设现有的DAC和TE策略已允许访问 ，则只有有权访问此类别的用户才能访问标有该类别的文件。MCS 的目的是维护系统上的数据机密性。

举个例子

在TE模型的例子中，我们将CAT和DOG定义为主体类型，并且只能访问指定资源类型的CAT_CHOWN 和DOG_CHOW。

现在，如果有多个 DOGS（如Fido和Spot），但Fido比较调皮，偷吃了Spot的DOG_CHOW，因此我们要阻止Fido吃Spot的DOG_CHOW：

如果使用TE模型，我们需要分别为Fido这个主体和属于它的资源DOG_CHOW创建新类型，如果要阻止其他DOG的类似行为则需要为每个DOG和他们的DOG_CHOW创建新类型。但是随着后续DOGS数量的增加，这样的方式很快将变的混乱，因为一般情况所有的狗都拥有吃DOG_CHOW的权限，但却需要为它们中每一个调皮者定义不同的新类型，显然调皮者是独立权限不能继承DOG类型的通用权限了。理想情况下，我们是希望每一只DOG都只能吃属于自己的DOG_CHOW。

为了解决这个问题，我们开发了一种新的执法形式，我们称之为多类别安全 (MCS)，这是基于TE的一种执法延伸。在 MCS 中，我们在TE基础上添加了标签的另一部分，将其附加应用于 DOG 主体和 DOG_CHOW 资源。现在我们将 DOG 进程标记为DOG:random1 (Fido) 和DOG:random2 (Spot)。

我们将狗食物标记为DOG_CHOW:random1 (Fido)和DOG_CHOW:random2 (Spot)：

MCS 策略为：如果类型强制策略正常且随机 MCS 标签完全匹配，则允许访问，否则拒绝访问，于是：

Fido (DOG:random1) 试图吃CAT_CHOW:food被TE拒绝。

Fido (DOG:random1) 被允许吃DOG_CHOW:random1。

Fido (DOG:random1) 被拒绝吃 spot ( DOG_CHOW:random2 ) 的食物。

同理，在人类的虚拟机生产环境中的例子：

如果我们有一台运行大量虚拟机的服务器，其中一个被黑客入侵，我想防止它攻击其他虚拟机和虚拟机镜像。

在TE中，KVM虚拟机被标记为svirt_t并且镜像被标记为svirt_image_t。我们有策略说svirt_t可以读取/写入/删除标记为svirt_image_t 的内容。

libvirt(虚拟机管理工具)不仅实现了TE分离，还实现了 MCS 分离，当 libvirt 即将启动虚拟机时，它会选择一个随机的 MCS 标签，如s0:c1,c2，然后将svirt_image_t:s0:c1,c2标签分配给虚拟机需要管理的所有数据内容。 最后，它以svirt_t:s0:c1,c2的形式启动虚拟机，SELinux 内核控制svirt_t:s0:c1,c2只能写入匹配的svirt_image_t:s0:c1,c2标签，不能写入其他任意标签如svirt_image_t:s0:c3,c4，即使虚拟机被黑客以root身份劫持。

2.5 MLS 模型​

多层级模型，简称MLS(Multi-Level Security) ，是指强制实施Bell-LaPadula模型的安全方案，主要思想是根据数据层级的差别来控制流程。

Bell-LaPadula模型 (BLP) 是一种状态机模型，用于在政府和军事应用中实施访问控制，它由 David Elliott Bell和 Leonard J. LaPadula 在Roger R. Schell的指导下开发，以正式确定美国国防部的MLS策略，最终研究论文发表于 1976 年。

在MLS下，用户和进程称为Subject(主体)，文件、设备和系统的其他组件称为Object(对象)。主体和对象都标有安全层级，每个安全层级都由一个敏感度(s0~s15)和一个类别组成。获得机密许可的用户读写机密类别中的文档，但不能查看绝密的文件，而允许写入绝密的文档(在被许可的情况下)，允许读取受限的和未分类的文档。

下图是美国国防部最初设计的许可层级，分为绝密(Top Secret)、机密(Secret)、受限的(Confidential )、未分类(Unclassified)。

下图显示了在“秘密”安全层级下运行的主体与具有不同安全层级的各种对象之间所有允许的数据流。

举个例子

我们现在不讨论不同的狗，而是讨论不同的品种。有一只灰狗和一只吉娃娃。

我们想让灰狗吃任何狗粮，但如果吉娃娃试图吃灰狗狗粮，它可能会窒息。

我们要将 Greyhound 标记为DOG:Greyhound并将其狗粮标记为DOG_CHOW:Greyhound， 并将 Chihuahua 标记为DOG:Chihuahua并将其食物标记为DOG_CHOW:Chihuahua。

使用 MLS 策略，我们让 MLS Greyhound 标签层级大于 Chihuahua 标签，这意味着DOG:Greyhound可以吃DOG_CHOW:Greyhound 和DOG_CHOW:Chihuahua。

但是DOG:Chihuahua不允许吃DOG_CHOW:Greyhound。

当然，DOG:Greyhound和DOG:Chihuahua通过TE仍然被阻止吃CAT_CHOW。

真实世界

有两台 Apache 服务器：一台作为httpd_t:TopSecret运行，另一台作为httpd_t:Secret运行。如果 Apache 进程httpd_t:Secret被黑客入侵，黑客可以读取httpd_sys_content_t:Secret 但无法读取httpd_sys_content_t:TopSecret。

如果运行httpd_t:TopSecret的 Apache 服务器被黑客入侵，它可以读取httpd_sys_content_t:Secret数据以及httpd_sys_content_t:TopSecret。

在军事环境中使用 MLS，可以允许用户查看机密数据，但同一系统上的另一个用户可以读取绝密数据。

参考链接​

强制访问控制(MAC)

Windows强制完整性控制(MIC)

什么是SELinux

SELinux 多层级安全(MLS)

MLS的理论支撑-贝尔-拉帕杜拉模型

有限状态机

可信计算机系统评估标准

SELinux 多类别安全性(MCS)

使用多类别安全性 (MCS) 保护数据机密性

为什么应该为 Linux 容器使用多类别安全性

SELinux 策略实施的可视化操作指南

意大利犬Fido

前言​

企业做为一个组织，存在明确的组织架构，由于每个人的职责不同因此对文件的访问范围也不同，随着企业信息化工程进一步完善，员工对文件的访问、共享、传递等需求越来越多，文件的访问便捷性和安全性之间的矛盾越来越大，我们需要学习当前世界流行的主要文件安全访问理论和现有成熟实践，设计一种专业的企业文件访问模型。

今天最著名的安全标准是TCSEC，全称是 Trusted Computer System Evaluation Criteria (可信计算机系统评估标准)，是美国国防部在 20 多年的研究和开发中发展出来的⼀组安全标准，于1985年12月公布，最初只是军用标准，后来延伸至民用领域。

TCSEC 规定了两种类型的访问控制标准：⾃主访问控制 (DAC) 和强制访问控制 (MAC)。DAC 的要求被认为在技术上对商业和⺠⽤政府安全需求以及单级军事系统是正确 的，而 MAC最初⽤于多级安全军事系统，目前这两种访问控制标准都已在Linux系统中实现，我们后续章节将以Linux系统为背景系统讲解这两种模型。

DAC模型​

Linux 系统上基础模型是 DAC, 全称是 Discretionary Access Control (自主访问控制)。

DAC模型是指对象(比如程序、文件、进程)的拥有者可以任意修改或者授予此对象相应的权限，也就是UGO+RWX/ACL权限控制。

权限有三个要素：主体(subject)、对象(object)、策略(policy)，用于表示主体对哪个对象拥有什么访问策略，例如：用户小明对\opt\work文件夹拥有读访问策略。

1.1 文件的UGO+RWX权限控制​

UGO

UGO是User(用户)、Group(用户所属组)和Other(其他用户)的简称：

User是文件的所有者(属主)，一般是创建文件的用户，对该文件具有完全的权限。在一台允许多个用户访问的 Linux 主机上，可以通过文件的所有者来区分一个文件属于那个用户。只有文件的属主和超级权限用户root 修改文件的权限。

Group是文件所属用户组对文件的访问权限(属组)。假如有几个用户合作开发同一个项目，如果每个用户只能查看和修改自己创建的文件就太不方便了，也就谈不上什么合作了。所以需要一个机制允许一个用户查看和修改其它用户的文件，此时就用到组的概念的。我们可以创建一个用户组，然后把需要合作的用户都添加都这个组中。在设置文件的访问权限时，允许这个组中的用户对该文件进行读取和修改。

Other是除了以上两种情况的其他用户对该文件的访问权限。如果我想把一个文件共享给系统中的所有用户该怎么办？通过组的方式显然是不合适的，因为需要把系统中的所有用户都添加到一个组中。并且系统中添加了新用户该怎么办，每添加一个新用户就把他添加到这个组中吗？这个问题可以通过其他人的概念解决。在设置文件的访问权限时，允许其他人户对该文件进行读取和修改。

RWX

RWX则是Read(读)、Write(写)、eXecute(执行)的简称：

每个文件或目录的访问权限都有三组，每组用三位表示，分别为文件属主的读、写和执行三种权限。当用命令 ls -l 显示详细信息时，最左边一列为文件的访问权限。例如：

# ls -al
-rw-------.   1 root root   132 7月   4 2019 .xauthQur1Xx
-rw-------.   1 root root   132 7月   4 2019 .xauthYacMAK
-rw-------.   1 root root   132 3月   8 2020 .xauthykfSZU
drwxr-xr-x.   7 root root   154 10月 21 09:39 ydisk
drwxr-xr-x.   3 root root    69 11月 30 2021 .ydisk

权限列共有 10 个字符，第一个字符为文件类型，后面九个分为三组：第一组为 U(User) ，即文件属主对应的权限；第二组为 G(Group)，即同组用户对应的权限；第三组为 O(Others)，即其他用户对应的权限。每个字符的意义可用下图描述：

权限列的第一个字符（文件类型），-代表普通文件；l代表链接文件；d代表目录文件。

文件与目录的权限有所区别，如下所示：

举例说明：

1. 对文件有 w 权限不能删除文件，需要对文件所在的目录有 w 权限；
2. 对目录有 w 权限不能 cd 进入目录，需要对目录有 x 权限；
3. 对目录有 x 权限，只有在知道文件名并且有 r 权限的时候才能访问目录下的文件；
4. 对目录必须有 x 权限才能 cd 进入到目录，必须有 rx 权限才能使用 ls 列出目录清单
5. 对目录有 w 权限，可以对目录中的任何文件或子目录进行创建、删除或修改操作，即使该文件或目录的所有者是其它用户也是如此。

1.2 文件的ACL权限控制​

ACL的全称是 Access Control List (访问控制列表) ，一个针对文件/目录的访问控制列表。它在UGO权限管理的基础上为文件系统提供一个额外的、更灵活的权限管理机制。它被设计为UNIX文件权限管理的一个补充。ACL允许你给任何用户或用户组设置任何文件/目录的访问权限。

在UGO+RWX权限中，用户对文件只有三种身份，就是属主、属组和其他人，但是在实际工作中，这三种身份实在是不够用，我们举个例子来看看：

根目录中有一个 /project 目录，这是班级的项目目录。班级中的每个学员都可以访问和修改这个目录，老师也需要对这个目录拥有访问和修改权限，其他班级的学员当然不能访问这个目录。需要怎么规划这个目录的权限呢？应该这样：老师使用 root 用户，作为这个目录的属主，权限为 rwx；班级所有的学员都加入 tgroup 组，使 tgroup 组作为 /project 目录的属组，权限是 rwx；其他人的权限设定为 0。这样这个目录的权限就可以符合我们的项目开发要求了。

有一天，班里来了一位试听的学员 st，她必须能够访问 /project 目录，所以必须对这个目录拥有 r 和 x 权限；但是她又没有学习过以前的课程，所以不能赋予她 w 权限，怕她改错了目录中的内容，所以学员 st 的权限就是 r-x。可是如何分配她的身份呢？变为属主？当然不行，要不 root 该放哪里？加入 tgroup 组？也不行，因为 tgroup 组的权限是 rwx，而我们要求学员 st 的权限是 r-x。如果把其他人的权限改为 r-x 呢？这样一来，其他班级的所有学员都可以访问 /project 目录了。

当出现这种情况时，普通权限中的三种身份就不够用了。ACL 权限就是为了解决这个问题的。在使用 ACL 权限给用户 st 陚予权限时，st 既不是 /project 目录的属主，也不是属组，仅仅赋予用户 st 针对此目录的 r-x 权限。这有些类似于 Windows 系统中分配权限的方式，单独指定用户并单独分配权限，这样就解决了用户身份不足的问题。

参考链接​

Linux 权限管理与访问控制详解

了解Linux操作系统的权限管理

Linux DAC权限管理详解

文件管理的权利问题​

专业的文件管理系统，在权限控制标准中通常选择基于角色的访问控制 (Role-based access control)，简称RBAC模型，这是一种围绕角色和权限定义的策略中立的访问控制机制，悦库企业网盘的权限管理也是基于这种模型。

在企业组织内，为各种工作职能创建角色，如“超级管理员”、“系统管理员”、“部门管理员”、“普通员工”，然后将文件操作的权限分配给特定角色，通过这些角色获得执行文件操作所需的权限，这样每个员工都有自己的文件访问范围，看起来井然有序。

但这种权限管理方法，存在一些安全问题：

1. 超级管理员拥有所有权限，是集权者，权利过大，行为不可控。

   “小明是某公司文件管理系统的超级管理员，因为与上司三观不合，提出离职，离职前小明将公司所有文件打包带走，给公司信息安全造成巨大隐患。”

2. 权限分配无人监督，存在越权访问问题。

   “小谢是某公司业务部门经理，拥有部门管理员权限，为了方便和一个重要客户共享资料，直接为该客户在内部文件管理系统中创建了账号并默认指定了可以访问本部门内文件的权限，导致公司重要文件外泄。

3. 系统运维人员，违规访问业务数据。

   “小王是某公司文件管理系统的运维人员，出于好奇，为自己创建了财务部门账号，下载并查看了一些员工的工资报表，然后将账号删除。”

从以上案例我们可以看出，虽然对文件的访问做了权限管理，但依然存在重大数据外泄隐患，其主要原因在于集权访问制度，即员工的操作行为不受他人监督，是否违规全凭自觉。

权利的平衡​

“一切有权力的人都容易滥用权力；要防止滥用权力，就必须以权力约束权力！” --- 法国启蒙思想家 孟德斯鸠

以权力约束权力使其保持平衡，是解决集权问题之道，于是我去寻找构建权利平衡的方法论：

去年到四川某部队出差，与安全部门主管对接文件管理需求时聊到文件管理的权利平衡问题，我们一致认可国家保密标准BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》中提出的“三员”管理概念，三权分立，用监督制约权利。

我查阅资料，有一些心得，下面与您分享。

三权的起源​

三权分立，是西方民主国家的基本政治制度的建制原则。三权分立原则起源于亚里士多德时代，他首次将国家的政权划分为议 事权、行政权和审判权。1680年，英国思想家洛克发表了《政府论》，主张治理权与统治权应当分离。随后，1748年，孟德斯鸠发表了《论法的精神》，其站在新兴资产阶级的立场上，提出了著名的“三权分立”。

三权分立主要阐述政府的立法权、司法权与行政权三权分离，各司其职，三种权力互相制约，防止掌权者权力的滥用。

三员概念​

“三员”，在国家保密标准BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》中提出，要求涉密信息系统应当配备系统管理员、安全保密员和安全审计员三类安全保密管理人员（简称为“三员”)，分别负责系统运行、安全保密管理和安全审计工作。“三员”担负维护系统安全、稳定、可靠运行的重要任务，对涉密信息系统和国家秘密安全具有重要作??。

“三员”在悦库企业网盘中落地​

“三员”并不是对RBAC模型的革新，而是基于RBAC模型之上构建的更为安全的权利管理体系，通过“三员”机制的实施，可以大幅度提高文件安全级别。

在悦库系统中的“三员”模式下，去除了超级管理员角色，为系统创建三种基础角色：“系统管理员”，“安全保密员”，“安全审计员”，如图：

“安全保密员” 负责为员工设置空间、文件夹、文件访问授权，为我的组织内员工变更角色（需低于安全保密员的角色权利值）。推荐由部门或项目组核心员工担任。

“系统管理员” 负责系统日常的运行维护工作，包括系统配置、新员工创建、员工的三员属性变更。可由公司普通运维人员担任。其中三员属性变更操作需安全审计员审核。

“安全审计员” 可接收系统的安全审计报告，审查我的组织中的“安全保密员”提交的文件访问授权，审查“系统管理员”的新建用户和运维报告，审批“系统管理员”提交的三员属性变更授权。推荐由部门主管或项目经理等领导层担任。

其他事项：

三员模型初始化时，需要确认三员属性拥有者，初始化操作有系统管理员触发，仅能触发一次。

任何人不能修改自身角色。

参考资料：

公安部等通知印发《信息安全等级保护管理办法》

基于角色的访问控制 (Role-based access control)

BMB20-2007《涉及国家秘密的信息系统分级保护管理规范》，是国家“秘密级”文件，传播违法。