生成钩子放置方案以实施预期的访问控制策略
在当今的数字化环境中,许多对安全敏感的程序需要代表相互不信任的客户端管理资源。为了控制对这些资源的访问,程序员通常会在程序中放置授权钩子。然而,手动放置钩子往往存在不完整或不正确的问题,导致程序存在安全隐患。本文将探讨如何自动生成授权钩子的放置方案,以实施预期的访问控制策略。
1. 引言
像数据库、Web 服务器、中间件和浏览器等代表相互不信任的客户端管理资源的程序,必须具备控制客户端请求处理操作访问的能力。程序员通过在程序中放置授权钩子来调解此类操作的访问。每个授权钩子守护一个或多个操作,使程序能够在运行时通过参考访问控制策略来决定是否执行这些操作。
在程序中放置授权钩子主要有两个步骤:
1.
定位安全敏感操作
:研究人员已经研究了多种技术,结合程序员的领域知识和自动程序分析来推断这些操作。
2.
确定授权钩子的放置位置
:这类似于在面向方面编程中找到连接点。以往的自动方法建议的钩子放置比程序员手动生成的放置更细粒度。
钩子放置的粒度会影响部署程序时所需编写的访问控制策略的粒度。细粒度的钩子放置会使访问控制策略变得复杂,阻碍程序部署。例如,在图 1 中的示例 (a) 中,自动方法在两个不同的安全敏感操作 O1 和 O2 处放置钩子。如果部署中有五个主体,那么策略可能需要多达 10 条规则来指定这五个主体应该有权访问这两个操作。
为了便于程序的广泛采用,程序员希望避免在部署时使用复杂的访问控制策略。因此,他们利用领域知识来权衡访问控制策略的灵活性,以换取简化的策略。例如,专家可能知道,当为程序指定策略时,每个被授权执行 O1 的主体也必须被授权执行 O2。在授权方面,O1 和 O2 是等效的,因此只需插入一个钩子来调解这两个操作,如图 1 的 (b) 部分所示,从而得到一个只有五条规则的较小策略。
钩子放置的最小化必须与执行机制的两个主要安全要求相平衡:
-
完全调解
:每个安全敏感操作之前都必须有一个适当的授权钩子。
-
最小特权原则
:访问控制策略只授权合法目的所需的权限。
目前,程序员需要手动在最小化、完全调解和最小特权之间进行权衡,这不仅延迟了必要安全措施的引入,而且在程序发布后仍需要进行多次改进。
2. 授权约束
我们认为,将程序员的领域知识明确化是解决授权钩子放置问题的关键。我们提出了一种基于程序员对程序操作(例如结构成员访问)指定约束的方法,我们称之为授权约束。授权约束限制了可以在一组操作上执行的访问控制策略。
我们的系统中使用了两种类型的约束:
-
操作等效性
:并行代码路径上的两个不同安全敏感操作必须为同一组主体授权,这使得可以使用一个授权钩子来调解这两个操作。
-
操作包含性
:被允许执行一个操作的主体也必须被允许执行第二个操作。因此,如果第二个操作在代码路径中跟随第一个操作,那么第二个操作的授权钩子是不必要的。
要使用授权约束自动放置授权钩子,我们需要克服两个挑战:
1.
最小化钩子放置
:开发一种方法,使用给定的授权约束来最小化放置的授权钩子数量,以执行满足这些约束的任何策略。
2.
发现授权约束
:提供一种方法来帮助程序员发现授权约束。
3. 最小化钩子放置
为了解决第一个挑战,我们开发了一种算法,使用授权约束来消除不必要的钩子。具体来说:
1. 当并行代码路径上的操作等效时,可以提升钩子放置。
2. 当相互包含的操作出现在同一控制流路径上时,可以移除冗余的钩子。
这种方法可以自动生成最小规模的钩子放置,能够执行满足授权约束的任何访问控制策略。
4. 发现授权约束
为了帮助程序员避免编写完整授权约束的繁琐任务,我们引入了约束选择器的概念。这些选择器能够根据更高级别的目标代表程序员做出一组约束选择。
例如,假设程序员的目标是让程序实施多级安全 (MLS) 策略,如使用 Bell - La Padula 模型表达的策略。Bell - La Padula 模型只考虑类似读取和类似写入的操作,因此任何两个仅对同一对象执行读取(或写入)的安全敏感操作是等效的。因此,MLS 的约束选择器会引导方法自动为这些操作创建等效约束。
我们设计并实现了一个源代码分析工具,用于生成授权钩子放置方案,减少手动决策,同时生成针对给定授权约束集最小化的放置方案。该工具只需要程序源代码和与该代码相关联的一组安全敏感操作,这些操作可以通过多种现有方法提供。
使用该工具,程序员可以选择约束选择器、建议的钩子放置和/或提升/移除选择的组合来构建一组授权约束。一旦建立了约束,工具会计算出相对于这些约束具有最少钩子数量的完整授权钩子放置方案。
我们发现,使用我们的工具可以将程序员需要考虑的可能放置决策数量减少多达 67%。重要的是,这种方法可以从细粒度的默认放置中移除许多不必要的钩子。例如,仅使用 MLS 约束选择器就可以从 X 服务器的默认细粒度放置中移除 124 个钩子。
5. 动机
5.1 钩子放置的背景
授权是通过检查主体在访问控制策略中是否具有授予其操作权限的许可,来确定主体(例如用户)是否被允许执行操作(例如读取或写入对象)的过程。授权是必要的,因为有些操作是安全敏感操作,并非所有主体都能执行这些操作,因此必须控制对这些操作的访问。
授权钩子是一个程序语句,用于向访问控制策略提交查询以检查是否有授权许可。由授权钩子守护的程序语句只有在授权请求之后才能执行(控制流支配)。否则,授权钩子将导致采取一些补救措施。
放置授权钩子的两个主要步骤是识别安全敏感操作和确定代码中必须放置授权钩子以调解这些操作的位置。过去的努力主要集中在第一个问题上,定义了识别安全敏感操作的技术。最初,这些技术要求程序员手动指定代码模式和/或安全敏感数据结构,这是复杂且容易出错的任务。随着时间的推移,程序员必须指定的信息量已经减少。
在授权钩子的放置方面,以往的方法通常建议在每个安全敏感操作之前放置一个钩子,以确保完全调解。但这种简单的方法存在两个问题:
1. 自动技术通常使用安全敏感操作的低级表示,如单个结构成员访问,这可能导致程序中散布着许多钩子。更多的授权钩子意味着程序员在维护和更新授权钩子时需要做更多的工作。
2. 这种放置可能导致冗余授权,因为一个钩子可能已经执行了与它支配的另一个钩子相同的授权。
5.2 手动放置与自动放置的差异
我们发现,领域专家在放置钩子时通常会进行两种优化:
1.
移除冗余钩子
:假设有两个自动放置的钩子 H1 和 H2,H1 在程序的控制流中支配 H2。领域专家的放置中有与 H1 匹配的钩子,但没有与 H2 匹配的钩子。这可以解释为专家移除了一个更细粒度的钩子,因为 H1 执行的访问检查使 H2 变得冗余。
2.
提升调解点
:自动工具在控制语句的分支处放置钩子 (H1, …, Hn)。而领域专家没有放置与这些钩子对应的钩子,而是放置了一个支配所有这些钩子的钩子 M1。专家将分支处操作的调解提升到控制语句上方的一个公共调解点。
例如,在图 2 中,函数 MAPWINDOW 对窗口执行 write(pWin→mapped) 操作,使窗口可见。程序员放置了一个钩子 m3::(pWin,ShowAccess) 来专门授权主体对 pWin 表示的对象执行此操作。MAPSUBWINDOWS 对窗口 pWin 的子窗口 pChild 执行相同的操作,但领域专家选择不放置相应的钩子。
另一个例子是 X 服务器中的 COPYGC 函数。该函数根据用户请求确定的掩码,通过一个 switch - case 控制语句将源对象的 23 个不同字段之一复制到目标对象。自动工具推断每个分支执行不同的安全敏感操作,因此建议在每个分支处放置一个不同的钩子。相反,有一个手动放置的单个钩子支配控制语句,该钩子检查客户端是否对源对象具有 DixGetAttrAccess 权限。因此,在这个例子中,一个手动放置的钩子取代了 23 个自动钩子。
/*** gc.c ***/
int CopyGC(GC *pgcSrc, GC *pgcDst, BITS32 mask){
switch (index2)
{
result = dixLookupGC(&pGC, stuff->srcGC,
client,DixGetAttrAccess);
if (result != Success)
return BadMatch;
case GCFunction:
/* Hook(pgcSrc, [read(GC->alu)]) */
pgcDst->alu = pgcSrc->alu;
break;
case GCPlaneMask:
/* Hook(pgcSrc, [read(GC->planemask)]) */
pgcDst->planemask = pgcSrc->planemask;
break;
case GCForeground:
/*
Hook(pgcSrc, [read(GC->fgPixel)]) */
pgcDst->fgPixel = pgcSrc->fgPixel;
break;
case GCBackground:
/* Hook(pgcSrc, [read(GC->bgPixel)]) */
pgcDst->bgPixel = pgcSrc->bgPixel;
break;
/* .... More similar cases */
}
}
5.3 平衡最小化与最小特权
在 X 服务器这样成熟的代码库中,程序员经过多年的研究才就钩子放置达成共识。专家们会根据具体情况谨慎选择放置哪些钩子以及避免哪些钩子。
例如,在图 2 的 CHANGEWINDOWPROPERTY 中,程序员在 m1::(pWin,SetPropertyAccess) 钩子之外,还放置了一个更细粒度的钩子 m4::(pProp,WriteAccess)。这与 MAPSUBWINDOWS 示例形成对比,在后者中,他们决定不调解子对象的访问。
手动编写的钩子放置和自动生成的钩子放置之间的根本区别在于安全敏感操作的定义粒度。自动工具在控制语句的每个分支处放置钩子时,隐含地以比专家更细的粒度识别安全敏感操作。安全敏感操作的粒度选择是在放置的钩子数量和最小特权之间进行权衡的过程。细粒度的放置可以更精确地控制主体的操作,但如果程序员决定主体必须以全有或全无的方式被授权访问操作,那么这种粒度可能就过于精细了。
即使是手动钩子放置,也可能需要多次迭代才能确定平衡最小特权和钩子放置最小化的粒度。例如,2007 年的 X 服务器版本只有四种操作模式,即读取、写入、创建和销毁。但在后续版本中,程序员将这些模式替换为 28 种访问模式,以指定和执行更细粒度的策略。自 2007 年 X 服务器首次发布带有 XACE 钩子以来,钩子已经经历了多次更改,包括添加、移除、移动或合并钩子。
综上所述,自动生成授权钩子的放置方案是解决手动放置问题的有效途径。通过引入授权约束和约束选择器,我们可以减少程序员的工作量,同时确保程序的安全性。未来,我们可以进一步研究如何优化这些方法,以适应更多的应用场景。
下面是一个简单的 mermaid 流程图,展示了授权钩子放置的主要步骤:
graph LR
A[定位安全敏感操作] --> B[确定授权钩子放置位置]
B --> C{是否使用授权约束}
C -- 是 --> D[应用约束选择器]
C -- 否 --> E[默认细粒度放置]
D --> F[计算最小化钩子放置]
E --> F
F --> G[生成访问控制策略]
表格展示手动放置和自动放置的对比:
| 放置方式 | 钩子数量 | 策略复杂度 | 灵活性 |
| ---- | ---- | ---- | ---- |
| 手动放置 | 较少 | 较低 | 较低 |
| 自动放置 | 较多 | 较高 | 较高 |
生成钩子放置方案以实施预期的访问控制策略
6. 技术贡献总结
我们的工作在解决授权钩子放置问题上取得了显著的成果,主要贡献可以总结为以下几点:
-
自动化最小化钩子放置
:我们引入了一种自动化方法,能够生成最小化的授权钩子放置方案,该方案可以执行满足一组授权约束的任何访问控制策略。通过利用操作等效性和操作包含性等授权约束,我们的算法能够智能地消除不必要的钩子,从而减少钩子的数量,同时确保策略的有效执行。
-
简化约束获取
:为了减轻程序员的负担,我们允许他们指定简单的高级安全目标,系统会自动将这些目标转换为授权约束。这种方式使得程序员无需手动详细编写复杂的授权约束,大大简化了约束获取的过程。
-
多程序评估
:我们在多个程序上对静态源代码分析方法进行了评估,结果表明该方法将程序员的搜索空间缩小了多达 58%,并将钩子数量减少了多达 30%。这充分证明了我们方法的有效性和实用性。
7. 实际应用案例分析
为了更直观地展示我们方法的优势,下面以几个实际应用案例进行分析。
7.1 X 服务器案例
X 服务器是一个广泛使用的图形服务器,其安全机制对于保障系统的稳定性和用户数据安全至关重要。在 X 服务器中,我们使用了 MLS 约束选择器,从默认的细粒度放置中移除了 124 个钩子。这不仅减少了钩子的数量,降低了维护成本,还简化了访问控制策略的编写。例如,在 COPYGC 函数中,原本自动放置的 23 个钩子被一个手动放置的钩子所取代,使得策略更加简洁明了。
7.2 数据库管理系统案例
在数据库管理系统中,对数据的访问控制是关键。我们的方法可以帮助管理员根据不同的安全需求,灵活地放置授权钩子。例如,对于一些敏感数据的操作,如数据删除和修改,我们可以使用操作包含性约束,确保只有被授权执行更高级别操作的用户才能进行这些操作。这样可以在保证数据安全的同时,减少不必要的钩子放置,提高系统的性能。
8. 未来研究方向
虽然我们的方法在解决授权钩子放置问题上取得了一定的成果,但仍有一些方面值得进一步研究和探索。
8.1 动态环境下的钩子放置
目前,我们的方法主要针对静态代码进行分析和钩子放置。然而,在实际应用中,许多系统是动态变化的,例如云计算环境和移动应用。未来的研究可以考虑如何在动态环境下实时调整钩子的放置,以适应系统的变化和安全需求。
8.2 与其他安全机制的集成
授权钩子放置只是系统安全的一个方面,未来的研究可以探索如何将我们的方法与其他安全机制,如加密技术、入侵检测系统等进行集成,以提供更全面的安全保障。
8.3 优化约束选择器
约束选择器是我们方法中的一个重要组成部分,未来可以进一步优化约束选择器的性能和功能。例如,开发更智能的约束选择器,能够根据不同的应用场景自动选择最合适的约束,提高系统的安全性和效率。
9. 总结
本文围绕授权钩子放置问题展开了深入研究,提出了一种基于授权约束和约束选择器的自动化方法。通过将程序员的领域知识明确化,我们能够有效地减少钩子的数量,简化访问控制策略的编写,同时确保程序的安全性和最小特权原则的实现。
在实际应用中,我们的方法已经在多个程序中得到了验证,取得了显著的效果。然而,为了更好地适应不断变化的安全环境和应用需求,未来还需要在动态环境下的钩子放置、与其他安全机制的集成以及优化约束选择器等方面进行深入研究。
下面是一个 mermaid 流程图,展示了未来研究方向的关系:
graph LR
A[动态环境下的钩子放置] --> B[与其他安全机制的集成]
A --> C[优化约束选择器]
B --> D[更全面的安全保障]
C --> D
表格展示未来研究方向的目标和挑战:
| 研究方向 | 目标 | 挑战 |
| ---- | ---- | ---- |
| 动态环境下的钩子放置 | 实时调整钩子放置以适应系统变化 | 准确捕捉系统动态变化,实时计算钩子放置 |
| 与其他安全机制的集成 | 提供更全面的安全保障 | 解决不同安全机制之间的兼容性问题 |
| 优化约束选择器 | 提高系统安全性和效率 | 开发更智能的约束选择算法 |
总之,我们相信通过不断的研究和改进,我们的方法将能够为更多的应用场景提供有效的安全解决方案,为保障系统的安全和稳定运行做出更大的贡献。
超级会员免费看
14

被折叠的 条评论
为什么被折叠?



