目录
1.2 AC Mechanisms and Policies
1.5 Access Control Lists (ACLs)
1.7 Capabilities: Implementations
1.8 Mandatory vs. Discretionary AC
1.10 Bell-LaPadula (BLP) Model
2.1 Initial Conditions for Attack
3. TRACE-BASED MODELLING IN DETAIL
3.2 Trace (Sequence of States)
1. ACCESS CONTROL
- who can access what in which ways
- the “who” are called subjects
- e.g. users, processes etc.
- the “who” are called subjects
- the “what” are called objects
- e.g. individual files, sockets, processes etc.
- includes all subjects
- the “ways” are called permissions
- e.g. read, write, execute etc.
- are usually specific to each kind of object
- include those meta-permissions that allow modification of the protection state
- e.g. own
- 访问控制是关于谁能以什么方式访问什么的问题。其中,“谁”被称为主体,如用户、进程等;“什么”被称为对象,如单个文件、套接字、进程等;“方式”被称为权限,如读取、写入、执行等。
- 访问控制包含所有主体,并且包括那些允许修改保护状态的元权限,如所有者权限。
1.2 AC Mechanisms and Policies
- AC Policy
- Specifies allowed accesses
- And how these can change over time
- AC Mechanism
- Implements the policy
- Certain mechanisms lend themselves to certain kinds of policies
- Certain policies cannot be expressed using certain mechanisms
- 访问控制策略规定了允许的访问方式以及这些访问方式如何随时间变化。
- 访问控制机制实现了访问控制策略。特定的机制适用于特定类型的策略,而有些策略不能使用特定的机制来表达。
1.3 Protection State
Access control matrix defines the protection state at any instant in time
此表格展示了在任何特定时间点,不同主体(Subj1, Subj2, Subj3)对不同对象(Obj1, Obj2, Obj3, Subj2)的访问权限。
1.4 Storing Protection State
- Not usually as access control matrix
- too sparse, inefficient
- Two obvious choices:
- store individual columns with each object
- defines the subjects that can access each object
- each such column is called the object’s access control list
- store individual columns with each object
- store individual rows with each subject
- defines the objects each subject can access
- each such is called the subject’s capability list
通常情况下,保护状态不是以访问控制矩阵的形式存储的,因为这种方式太过稀疏,效率不高。有两个明显的选择:
- 将每个对象的各个列存储起来,定义了可以访问每个对象的主体,这种列被称为对象的访问控制列表(Access Control List,ACL)。
- 将每个主体的各个行存储起来,定义了每个主体可以访问的对象,这种行被称为主体的能力列表(Capability List)。
1.5 Access Control Lists (ACLs)
- Subjects usually aggregated into classes
- e.g. UNIX: owner, group, everyone 、
- Meta-permissions (e.g. own)
- control class membership
- allow modifying the ACL
- Implemented in almost all commercial OSes
- 主体通常被聚合到类中,如UNIX中的所有者、组、每个人。
- 元权限(如所有者权限)控制类成员资格,允许修改ACL。
- 几乎所有的商业操作系统都实现了ACLs。例如:
此表格展示了对于对象Obj1,不同主体(Subj1, Subj2, Subj3)的访问权限。
1.6 Capabilities
- A capability is a capability list element
-
- Names an object to which the capability refers
- Confers permissions over that object
- Less common in commercial systems
- More common in research though
此表格展示了对于主体Subj1,它对不同对象(Obj1, Obj2, Obj3, Subj2)的访问权限。
1.7 Capabilities: Implementations
- Capabilities must be unforgeable
- On conventional hardware, either:
- Stored as ordinary user-level data, but unguessable due to sparseness
- like a password or an encryption key
- Stored separately (in-kernel), referred to by user programs by index/ address
- like UNIX file descriptors
- Stored as ordinary user-level data, but unguessable due to sparseness
- Sparse capabilities can be leaked more easily, but are easier to revoke
- The only solution for most distributed systems
- 能力必须是不可伪造的。在传统硬件上,能力可以以以下两种方式存储:
- 存储为普通用户级数据,但由于稀疏性而不可预测,就像密码或加密密钥。
- 单独存储(在内核中),由用户程序通过索引/地址引用,就像UNIX文件描述符。
- 稀疏的能力更容易泄露,但更容易撤销。这是大多数分布式系统的唯一解决方案。
1.8 Mandatory vs. Discretionary AC
- Discretionary Access Control:
- Users can make access control decisions
- delegate their access to other users etc.
- Users can make access control decisions
- Mandatory Access Control (MAC):
- enforcement of administrator-defined policy
- users cannot make access control decisions (except those allowed by mandatory policy)
- can prevent untrusted applications running with user’s privileges from causing damage
- 自主访问控制:用户可以做出访问控制决策,将他们的访问权限委派给其他用户等。
- 强制访问控制:强制执行管理员定义的策略,用户不能做出访问控制决策(除非强制策略允许)。可以防止以用户权限运行的不受信任的应用程序造成损害。
1.9 MAC
- Common in areas with global security requirements 常见于有全球安全要求的领域
- e.g. national security classifications 例如,国家安全分类
- Less useful for general-purpose settings: 对一般用途的设置不太有用:
- hard to support different kinds of policies 难以支持不同种类的政策
- all policy changes must go through sysadmin 所有的政策变化必须经过系统管理员
- hard to dynamically delegate only specific rights required at runtime 很难在运行时只动态地授予所需的特定权限
1.10 Bell-LaPadula (BLP) Model
- MAC Policy/Mechanism
- Formalises National Security Classifications
- Every object assigned a classification
- e.g. TS, S, C, U
- Classifications ordered in a lattice
- e.g. TS > S > C > U
- Every subject assigned a clearance
- Highest classification they’re allowed to learn
BLP模型是强制访问控制的策略/机制,它形式化了国家安全级别分类。每个对象都分配有一个分类,如最高机密(TS),秘密(S),机密(C),未分类(U)。分类在阶梯上有序,如TS > S > C > U。每个主体都分配有一个许可证,这是他们被允许获知的最高分类。
1.11 BLP: Rules
- Simple Security Property (“no read up”):
- s can read o iff clearance(s) >= class(o)
- S-cleared subject can read U,C,S but not TS
- standard confidentiality
- *-Property (“no write down”):
- s can write o iff clearance(s) <= class(o)
- S-cleared subject can write TS,S, but not C,U
- to prevent accidental or malicious leakage of data to lower levels
- 简单安全属性("no read up"):主体s只能读取对象o,当且仅当clearance(s) >= class(o)。S级别的主体可以读取U,C,S,但不能读取TS。这是标准的保密性。
- *-属性("no write down"):主体s只能写入对象o,当且仅当clearance(s) <= class(o)。S级别的主体可以写入TS,S,但不能写入C,U。这是为了防止数据意外或恶意泄露到较低级别。
1.12 Boebert’s Attack
- Boebert 1984: “On the Inability of an Unmodified Capability Machine to Enforce the *-Property“
- Shows an attack on sparse capability systems that violates the *-property
- Where caps and data are indistinguishable
- Does not work against partitioned capability systems
- Practically all capability-based kernels
Boebert在1984年提出了一种攻击,它针对稀疏能力系统,破坏了*-属性。当能力和数据无法区分时,这种攻击就会发生。这种攻击不能对分区能力系统造成影响。实际上,所有基于能力的内核都是安全的。
2. LET’S MODEL THIS IN ALLOY
2.1 Initial Conditions for Attack
- 表示为:Low ---RW--rw_I--> LoSeg <--R--r_I-- High ---R--> HiSeg
- 这是系统的初始状态,其中Low,High是程序,LoSeg,HiSeg是存储数据的内存段。
- “RW”和“R”是访问权限。"RW"代表读/写权限,"R"代表只读权限。
- "rw_I"和"r_I"是能力(capabilities),指向内存段并携带特定的访问权限。
2.2 What we need to model
- 数据:储存在内存段中的信息。
- 能力:每一个都指向一个对象并带有特定的访问权限(权限)。
- 对象:能力指向的事物;每一个都有一个分类(High或Low)。
- 主体(如程序):可以使用其所拥有的能力。
- 内存段:存储数据。
2.3 Boebert’s Attack
- Low writes his cap into the low segment
- from which High reads it out
- 表示为:Low (rw_l.write(rw_l)) ---RW--rw_I--> LoSeg <--RW--R--r_I-- High (r_l.read()) ---R--> HiSeg
- 在此攻击中,低级别的程序(Low)将其能力(rw_l)写入低级别的内存段(LoSeg)。高级别的程序(High)可以从LoSeg中读取这个能力。
- 攻击的关键在于,Low的能力(rw_l)被写入了LoSeg,并且High能够读取到它。这意味着High程序可以使用Low的能力。
2.4 Boebert’s Attack: Lessons
- Not all mechanisms suited to all policies
- Many policies treat data- and access-propagation differently
- BLP is one example
- Cannot be expressed using sparse capability systems
- This does not mean that capability systems and MAC are incompatible in general
- 并非所有机制都适合所有政策。
- 许多策略对数据传播和访问权限传播有不同的处理方式。
- Bell-LaPadula (BLP)模型就是一个例子,它无法使用稀疏能力系统来表达。
- 这并不意味着能力系统和强制访问控制(MAC)在一般情况下是不兼容的。
3. TRACE-BASED MODELLING IN DETAIL
3.1 Trace-Based Modelling
不能只考虑单个状态转换,需要讨论一系列(跟踪)的状态转换。
3.2 Trace (Sequence of States)
3.3 Traces in Alloy
- Alloy 6 原生支持对跟踪的推理。
- Alloy考虑的模型(行为)(例如在执行检查和运行时)是"lasso traces"。
- 我们需要为这些跟踪赋予意义,限制状态转换以及(通常)限制第一个状态。
3.4 Defining Traces
We need to give these traces meaning
Constrain the state transitions:
fact trans { always all s: State | op1[s] or op2[s] or … or unchanged[s] }
(Often, also) constrain the first state: fact init { all s: State | init[s] }
- 我们需要为这些跟踪赋予意义。
- 约束状态转换:
- fact trans { always all s: State | op1[s] or op2[s] or … or unchanged[s] }
- (通常,也)约束第一个状态:
- fact init { all s: State | init[s] }
3.5 Summary
-
Boebert's Attack:在这个例子中,Boebert的攻击是指一个低权限级别的程序能够通过将其能力写入一个低级别的内存段,并且这个能力能够被一个高权限级别的程序读取出来,这样高权限级别的程序就能够以低权限级别的程序的能力进行操作,破坏了系统的安全。在现实生活中,这类攻击一般是指一个低权限用户试图提升自己的权限,或者是通过某种方式让一个高权限用户执行低权限用户的命令。
-
强制访问控制(MAC)与能力系统:强制访问控制是一种安全策略,只有系统管理员才能设置访问控制策略,而用户不能更改。这种方法可以有效地防止恶意软件对系统造成破坏。能力系统则是一种不同的安全策略,它允许每个用户持有一组“能力”,每个能力都表示用户可以执行某种操作(如读取文件,修改文件等)。这种系统的优点是灵活性,可以很容易地给每个用户分配适当的权限。然而,Boebert的攻击显示,这两种系统在某些情况下可能存在兼容性问题。在具体设计系统的时候,需要充分考虑到这些安全问题。
-
跟踪和状态转换:在很多系统中,我们不仅关心系统在单个时间点的状态,还关心系统状态随时间的变化,即系统的行为。这就涉及到了状态转换和跟踪的概念。状态转换是指系统从一个状态变化到另一个状态,跟踪则是指一系列的状态转换。在很多情况下,我们不仅要验证系统的每个状态是否满足某种性质,还要验证系统的行为是否满足某种性质。这就需要基于跟踪的建模。
-
Alloy中的跟踪:Alloy是一个能够自然地描述和分析状态转换和跟踪的工具。在Alloy中,你可以定义一个状态的数据类型,以及一个转换函数,描述系统从一个状态如何转换到另一个状态。你还可以定义一系列的断言和事实,来限制可能的状态和转换。通过运行Alloy分析器,你可以自动检查模型的所有可能的状态和行为,看它们是否满足你的性质。这种基于跟踪的建模和分析方法可以帮助你更深入地理解你的系统,并在设计阶段就找到潜在的问题。