关于OpenBSD操作系统中Pledge和Unveil系统调用采用情况的测量研究

# 关于OpenBSD操作系统中pledge和unveil系统调用采用情况的测量研究
来源：https://arxiv.org/html/2607.03056
###### 摘要

本文对OpenBSD中pledge和unveil系统调用的采用情况进行了纵向测量研究。这些系统调用用于对程序和库进行沙箱化。基于涵盖19个版本的数据集，许多程序和库早在这些系统调用正式发布之前就已经被修改以使用它们。采用率也在稳步增长；线性趋势提供了一个粗略但合理的启发式方法。尽管/usr/bin和/usr/sbin中的程序尤其已被修改以使用这些系统调用，但程序和库的大小与调用的pledge和unveil系统调用数量之间并没有良好的相关性。关于所做的承诺，标准输入/输出操作经常被请求，尽管pledge提供的完整细粒度功能在OpenBSD中总体上已被利用。同样观察到，对给定路径的读取操作尤其经常被揭示。总体而言，测量结果表明，系统调用最小化和沙箱化技术的采用并不像文献中常讨论的那样困难。

## I引言

大约十年前，开源操作系统OpenBSD引入了一个新的pledge系统调用，用于最小化与系统调用相关的攻击面。unveil系统调用随后诞生。这两个系统调用在开源软件世界中引起了关注，不仅因为其安全性本身，还因为其简洁性以及与其它相关安全解决方案相比不同的实现策略[1 (https://arxiv.org/html/2607.03056#bib.bib1),2 (https://arxiv.org/html/2607.03056#bib.bib2)]。然而，学术界的关注有限。事实上，似乎只有两项近期工作对该主题进行了实证研究，且这些研究基于访谈以及OpenBSD和其它开源操作系统中分发的外部软件包的快照[3 (https://arxiv.org/html/2607.03056#bib.bib3),4 (https://arxiv.org/html/2607.03056#bib.bib4)]。因此，本工作继续先前的研究，通过检查pledge和unveil在OpenBSD自身（即由OpenBSD开发者在其源代码树中明确开发和维护的软件）中的纵向采用情况。此外，还提供了对pledge和unveil的更详细观察。

本文的整体动机基于先前工作中提出的关于采用系统调用最小化和沙箱化技术困难性的论点[3 (https://arxiv.org/html/2607.03056#bib.bib3)]。后来关于Linux中seccomp沙箱解决方案的研究证实，即使是有经验的开发者在尝试沙箱化软件时也面临诸多困难[4 (https://arxiv.org/html/2607.03056#bib.bib4)]。尽管下文没有明确观察到困难和工作量，但观察到的采用率可以揭示OpenBSD的沙箱解决方案是否已在整个操作系统中推广——尽管存在潜在的困难和障碍。它们还可以表明pledge和unveil在设计之初是否具有良好的灵活性，以便将其应用于不同的程序和库。在这方面，有人认为seccomp“过于强大”[4 (https://arxiv.org/html/2607.03056#bib.bib4), p. 1]，因为它提供了完整的沙箱工具箱。相比之下，且符合Unix哲学[5 (https://arxiv.org/html/2607.03056#bib.bib5)]，pledge和unveil系统调用使用起来相当简单——至少在纸面上是这样。

关于剩余结构，首先在开篇的第II节 (https://arxiv.org/html/2607.03056#S2)中阐述了背景。该节还引入了四个用于实证测量分析的研究问题。数据和方法在第III节 (https://arxiv.org/html/2607.03056#S3)中介绍，随后结果在第IV节 (https://arxiv.org/html/2607.03056#S4)中呈现。最后三节，即第V节 (https://arxiv.org/html/2607.03056#S5)、第VI节 (https://arxiv.org/html/2607.03056#S6)和第VII节 (https://arxiv.org/html/2607.03056#S7)，分别介绍了结论、若干局限性以及两点结束语。

## II背景

### II-A系统调用最小化

攻击面最小化是一种经典的安全工程技术。它也是欧洲近期法规的要求，最小化技术包括从禁用或移除不必要的功能到减少无线信号传播等各个方面[6 (https://arxiv.org/html/2607.03056#bib.bib6),7 (https://arxiv.org/html/2607.03056#bib.bib7)]。由于缺乏普遍接受的定义[8 (https://arxiv.org/html/2607.03056#bib.bib8)]，在本文中，攻击面和攻击面最小化这两个术语被限制在操作系统中的系统调用及其对用户空间进程的缩减。尽管有此限制，传统逻辑仍然适用；一个运行中的进程可用的不必要系统调用越多，操作系统通过该进程面临的攻击面就越大。除了在操作系统内核本身中粗暴地禁用系统调用外，沙箱化用户空间进程也是一种常见技术，因此pledge和unveil系统调用也常被称为沙箱技术[3 (https://arxiv.org/html/2607.03056#bib.bib3),9 (https://arxiv.org/html/2607.03056#bib.bib9)]。从根本上说，问题在于操作系统及其内核提供了过多的功能，因此使用沙箱技术的开发者试图“尽可能阻止”，引用一项现有研究中受访者的评论[4 (https://arxiv.org/html/2607.03056#bib.bib4), p. 4]。

通过系统调用最小化来减少攻击面的想法并不新鲜[10 (https://arxiv.org/html/2607.03056#bib.bib10)]。它也不断被应用于新的场景，包括二进制文件[6 (https://arxiv.org/html/2607.03056#bib.bib6)]和虚拟化技术[11 (https://arxiv.org/html/2607.03056#bib.bib11),12 (https://arxiv.org/html/2607.03056#bib.bib12),13 (https://arxiv.org/html/2607.03056#bib.bib13)]。OpenBSD在系统调用最小化实现方面也有悠久传统。

关于历史和OpenBSD的软件演进，源自21世纪初的基于策略的systrace工具[14 (https://arxiv.org/html/2607.03056#bib.bib14)]于2016年在引入pledge后从OpenBSD中弃用。pledge和unveil系统调用也直接在源代码中使用。它们的基本思想接近于Linux中可用的seccomp系统调用[15 (https://arxiv.org/html/2607.03056#bib.bib15)]以及FreeBSD中基于能力的capsicum实现[16 (https://arxiv.org/html/2607.03056#bib.bib16),17 (https://arxiv.org/html/2607.03056#bib.bib17)]。用OpenBSD的行话来说，软件开发者通过pledge“承诺”只使用某些系统调用及其特性。例如，经典的hack游戏（关于“探索毁灭地牢”[18 (https://arxiv.org/html/2607.03056#bib.bib18)]）仅承诺使用标准输入和输出：

```
if (pledge("stdio", NULL) == -1)
             err(1, "pledge");
```

如果带有pledge标注的给定进程在运行时未能遵守其承诺，内核将终止该进程并报告。隐式地且理论上，类似的思想也可以看作是在不同断言（用于验证前提条件和软件的未来行为）的底层工作[19 (https://arxiv.org/html/2607.03056#bib.bib19)]。unveil系统调用是对pledge的补充。使用该系统调用时，开发者试图限制对文件系统的访问；每次尝试访问未明确揭示的路径都会返回错误。

### II-B益处

pledge和unveil系统调用具有许多安全优势，因为它们允许在运行时进行细粒度限制。例如，权限降级和权限分离都受益于pledge系统调用的使用[20 (https://arxiv.org/html/2607.03056#bib.bib20),21 (https://arxiv.org/html/2607.03056#bib.bib21)]。（前者意味着必须以root权限启动的进程稍后会将权限降级为普通受限用户的权限；后者意味着必须以root权限运行的进程仅以最小权限运行，将许多功能外包给其他子进程及其自己的用户。）同样，限制对文件系统的访问也有其直截了当的理由。鉴于“安全中的简洁是一种美德”，“被攻破的进程无法读取它无法读取的数据，也无法破坏它无法写入的文件”[2 (https://arxiv.org/html/2607.03056#bib.bib2)]。因此，unveil的总体理由可以与其他文件系统完整性解决方案（如NetBSD中基于策略的veriexec子系统[22 (https://arxiv.org/html/2607.03056#bib.bib22)]）相比较。不同之处再次在于，unveil调用直接在源代码中使用。

### II-C采用挑战

然而，也存在实际挑战。由于各种原因，包括知识差距和工作量要求，软件安全技术和特性的采用存在众所周知且持久的挑战[23 (https://arxiv.org/html/2607.03056#bib.bib23)]。尽管情况多年来有所改善，但特别是主动、预防性安全工程技术和特性的采用已被观察到比被动技术（包括处理软件漏洞）的采用更慢[24 (https://arxiv.org/html/2607.03056#bib.bib24)]。一个可能的解释可能与观察结果有关，即许多安全工程活动往往集中在产品发布前的开发后验证上[25 (https://arxiv.org/html/2607.03056#bib.bib25)]。因此，对沙箱技术（包括特别针对pledge、seccomp和unveil）的批评也就不足为奇了[3 (https://arxiv.org/html/2607.03056#bib.bib3),12 (https://arxiv.org/html/2607.03056#bib.bib12),13 (https://arxiv.org/html/2607.03056#bib.bib13)]。尽管有研究，自动化仍然是一个挑战[12 (https://arxiv.org/html/2607.03056#bib.bib12)]，以及其他问题。类似的批评也适用于基于策略的解决方案，例如安全增强型Linux（SELinux）实现[26 (https://arxiv.org/html/2607.03056#bib.bib26)]。特别是在其他开发者需要做这项工作的情况下，据推测很难让他们采用安全技术。调试既困难又耗时。话虽如此，应该注意到类似的观点也更普遍地适用；例如，新应用程序编程接口的采用已被观察到是缓慢的[27 (https://arxiv.org/html/2607.03056#bib.bib27)]。

这些潜在的采用挑战已被OpenBSD开发者隐式承认，他们列出了各种调试工具来帮助开发者采用pledge和unveil[15 (https://arxiv.org/html/2607.03056#bib.bib15),21 (https://arxiv.org/html/2607.03056#bib.bib21)]。话虽如此，BSD操作系统在这方面有优势，因为它们是完整的操作系统，意味着它们有自己的内核和非内核用户空间。因此，采用挑战可能更多地在于通过OpenBSD软件包管理器提供的外部软件。在这方面，有批评指出，特别是对于大型和复杂的软件，采用可能很困难[9 (https://arxiv.org/html/2607.03056#bib.bib9)]。由于本文仅限于OpenBSD不断演进的用户空间，这些关于潜在采用挑战的要点并未得到尽可能全面的研究。尽管如此，一个案例研究（关于“在其自然环境中研究当代现象”[28 (https://arxiv.org/html/2607.03056#bib.bib28), p. 131]）有助于理解pledge和unveil在其自然环境中（即OpenBSD操作系统）被采用的程度。据作者所知，本文也是首次对系统调用的纵向采用进行实证研究。

### II-D研究问题

上述讨论引出了以下四个研究问题（RQs），用于指导实证分析：

- • RQ.1：在OpenBSD的近期历史中，pledge和unveil的采用率如何？
- • RQ.2：软件大小是否影响了采用率？
- • RQ.3：通过pledge经常承诺什么，以及通过unveil经常揭示什么？
- • RQ.4：无论RQ.1的答案如何，各个版本之间的承诺和揭示是否稳定？

通过这些研究问题，本文进一步与大型实证软件进化研究分支交织在一起。在这方面，Linux内核一直是案例研究的热门选择[19 (https://arxiv.org/html/2607.03056#bib.bib19)]。尽管有针对BSD操作系统的案例研究和比较研究[29 (https://arxiv.org/html/2607.03056#bib.bib29),30 (https://arxiv.org/html/2607.03056#bib.bib30),31 (https://arxiv.org/html/2607.03056#bib.bib31),32 (https://arxiv.org/html/2607.03056#bib.bib32)]，包括专门针对OpenBSD的[3 (https://arxiv.org/html/2607.03056#bib.bib3),33 (https://arxiv.org/html/2607.03056#bib.bib33)]，但与涉及Linux和开源软件的研究相比，它们的数量似乎有限。因此，关于OpenBSD新安全特性的案例研究也为实证软件工程知识做出了一个小贡献。

## III材料与方法

### III-A数据

pledge系统调用首次出现在OpenBSD 5.9中，而unveil稍晚一些，在6.4版本中引入[34 (https://arxiv.org/html/2607.03056#bib.bib34),35 (https://arxiv.org/html/2607.03056#bib.bib35)]。因此，数据集（也可在线获取用于复制[36 (https://arxiv.org/html/2607.03056#bib.bib36)）基于从OpenBSD 5.9到7.7的版本。覆盖的时间范围从2016年3月到2025年4月。7.7版本是撰写本文时的最新版本。总共观测了1919个版本。尽管这个数量对于使用正式时间序列方法来说属于边缘情况，但大约十年的日历时间跨度足以回答RQ.1和RQ.4。

存档的（src.tar.gz）源代码树是从一个存档了OpenBSD完整历史的镜像中检索到的。222https://mirror.leaseweb.com/pub/OpenBSD/通过采用相关工作中使用的解析策略[19 (https://arxiv.org/html/2607.03056#bib.bib19)]，数据集是通过逐行处理每个以.c结尾的文件构建的，通过查找pledge和unveil字符串后跟左括号的出现来识别承诺和揭示。排除了OpenBSD源代码树中的distrib、gnu、regress和sysroot目录。这些目录包含附带GNU许可的捆绑软件、回归测试、内核代码和杂项文件。

### III-B度量与测量

测量分析涉及对两个系统调用的调用次数以及这些调用的参数计数。关于后者计数，测量侧重于传递给pledge的第一个参数和传递给unveil的第二个参数。这些将在第IV-C (https://arxiv.org/html/2607.03056#S4.SS3)子节呈现结果时进一步阐述。目前，只需注意传递给pledge的第二个参数被省略，因为几乎所有参数都是NULL值，而传递给unveil的第二个参数涉及授予作为第一个参数提供的路径的权限。# 关于OpenBSD操作系统中pledge和unveil系统调用采用情况的测量研究
来源：https://arxiv.org/html/2607.03056
###### 摘要

本文对OpenBSD中pledge和unveil系统调用的采用情况进行了纵向测量研究。这些系统调用用于对程序和库进行沙箱化。基于涵盖19个版本的数据集，许多程序和库早在这些系统调用正式发布之前就已经被修改以使用它们。采用率也在稳步增长；线性趋势提供了一个粗略但合理的启发式方法。尽管/usr/bin和/usr/sbin中的程序尤其已被修改以使用这些系统调用，但程序和库的大小与调用的pledge和unveil系统调用数量之间并没有良好的相关性。关于所做的承诺，标准输入/输出操作经常被请求，尽管pledge提供的完整细粒度功能在OpenBSD中总体上已被利用。同样观察到，对给定路径的读取操作尤其经常被揭示。总体而言，测量结果表明，系统调用最小化和沙箱化技术的采用并不像文献中常讨论的那样困难。

## I引言

大约十年前，开源操作系统OpenBSD引入了一个新的pledge系统调用，用于最小化与系统调用相关的攻击面。unveil系统调用随后诞生。这两个系统调用在开源软件世界中引起了关注，不仅因为其安全性本身，还因为其简洁性以及与其它相关安全解决方案相比不同的实现策略[1 (https://arxiv.org/html/2607.03056#bib.bib1),2 (https://arxiv.org/html/2607.03056#bib.bib2)]。然而，学术界的关注有限。事实上，似乎只有两项近期工作对该主题进行了实证研究，且这些研究基于访谈以及OpenBSD和其它开源操作系统中分发的外部软件包的快照[3 (https://arxiv.org/html/2607.03056#bib.bib3),4 (https://arxiv.org/html/2607.03056#bib.bib4)]。因此，本工作继续先前的研究，通过检查pledge和unveil在OpenBSD自身（即由OpenBSD开发者在其源代码树中明确开发和维护的软件）中的纵向采用情况。此外，还提供了对pledge和unveil的更详细观察。

本文的整体动机基于先前工作中提出的关于采用系统调用最小化和沙箱化技术困难性的论点[3 (https://arxiv.org/html/2607.03056#bib.bib3)]。后来关于Linux中seccomp沙箱解决方案的研究证实，即使是有经验的开发者在尝试沙箱化软件时也面临诸多困难[4 (https://arxiv.org/html/2607.03056#bib.bib4)]。尽管下文没有明确观察到困难和工作量，但观察到的采用率可以揭示OpenBSD的沙箱解决方案是否已在整个操作系统中推广——尽管存在潜在的困难和障碍。它们还可以表明pledge和unveil在设计之初是否具有良好的灵活性，以便将其应用于不同的程序和库。在这方面，有人认为seccomp“过于强大”[4 (https://arxiv.org/html/2607.03056#bib.bib4), p. 1]，因为它提供了完整的沙箱工具箱。相比之下，且符合Unix哲学[5 (https://arxiv.org/html/2607.03056#bib.bib5)]，pledge和unveil系统调用使用起来相当简单——至少在纸面上是这样。

关于剩余结构，首先在开篇的第II节 (https://arxiv.org/html/2607.03056#S2)中阐述了背景。该节还引入了四个用于实证测量分析的研究问题。数据和方法在第III节 (https://arxiv.org/html/2607.03056#S3)中介绍，随后结果在第IV节 (https://arxiv.org/html/2607.03056#S4)中呈现。最后三节，即第V节 (https://arxiv.org/html/2607.03056#S5)、第VI节 (https://arxiv.org/html/2607.03056#S6)和第VII节 (https://arxiv.org/html/2607.03056#S7)，分别介绍了结论、若干局限性以及两点结束语。

## II背景

### II-A系统调用最小化

攻击面最小化是一种经典的安全工程技术。它也是欧洲近期法规的要求，最小化技术包括从禁用或移除不必要的功能到减少无线信号传播等各个方面[6 (https://arxiv.org/html/2607.03056#bib.bib6),7 (https://arxiv.org/html/2607.03056#bib.bib7)]。由于缺乏普遍接受的定义[8 (https://arxiv.org/html/2607.03056#bib.bib8)]，在本文中，攻击面和攻击面最小化这两个术语被限制在操作系统中的系统调用及其对用户空间进程的缩减。尽管有此限制，传统逻辑仍然适用；一个运行中的进程可用的不必要系统调用越多，操作系统通过该进程面临的攻击面就越大。除了在操作系统内核本身中粗暴地禁用系统调用外，沙箱化用户空间进程也是一种常见技术，因此pledge和unveil系统调用也常被称为沙箱技术[3 (https://arxiv.org/html/2607.03056#bib.bib3),9 (https://arxiv.org/html/2607.03056#bib.bib9)]。从根本上说，问题在于操作系统及其内核提供了过多的功能，因此使用沙箱技术的开发者试图“尽可能阻止”，引用一项现有研究中受访者的评论[4 (https://arxiv.org/html/2607.03056#bib.bib4), p. 4]。

通过系统调用最小化来减少攻击面的想法并不新鲜[10 (https://arxiv.org/html/2607.03056#bib.bib10)]。它也不断被应用于新的场景，包括二进制文件[6 (https://arxiv.org/html/2607.03056#bib.bib6)]和虚拟化技术[11 (https://arxiv.org/html/2607.03056#bib.bib11),12 (https://arxiv.org/html/2607.03056#bib.bib12),13 (https://arxiv.org/html/2607.03056#bib.bib13)]。OpenBSD在系统调用最小化实现方面也有悠久传统。

关于历史和OpenBSD的软件演进，源自21世纪初的基于策略的systrace工具[14 (https://arxiv.org/html/2607.03056#bib.bib14)]于2016年在引入pledge后从OpenBSD中弃用。pledge和unveil系统调用也直接在源代码中使用。它们的基本思想接近于Linux中可用的seccomp系统调用[15 (https://arxiv.org/html/2607.03056#bib.bib15)]以及FreeBSD中基于能力的capsicum实现[16 (https://arxiv.org/html/2607.03056#bib.bib16),17 (https://arxiv.org/html/2607.03056#bib.bib17)]。用OpenBSD的行话来说，软件开发者通过pledge“承诺”只使用某些系统调用及其特性。例如，经典的hack游戏（关于“探索毁灭地牢”[18 (https://arxiv.org/html/2607.03056#bib.bib18)]）仅承诺使用标准输入和输出：

```
if (pledge("stdio", NULL) == -1)
             err(1, "pledge");
```

如果带有pledge标注的给定进程在运行时未能遵守其承诺，内核将终止该进程并报告。隐式地且理论上，类似的思想也可以看作是在不同断言（用于验证前提条件和软件的未来行为）的底层工作[19 (https://arxiv.org/html/2607.03056#bib.bib19)]。unveil系统调用是对pledge的补充。使用该系统调用时，开发者试图限制对文件系统的访问；每次尝试访问未明确揭示的路径都会返回错误。

### II-B益处

pledge和unveil系统调用具有许多安全优势，因为它们允许在运行时进行细粒度限制。例如，权限降级和权限分离都受益于pledge系统调用的使用[20 (https://arxiv.org/html/2607.03056#bib.bib20),21 (https://arxiv.org/html/2607.03056#bib.bib21)]。（前者意味着必须以root权限启动的进程稍后会将权限降级为普通受限用户的权限；后者意味着必须以root权限运行的进程仅以最小权限运行，将许多功能外包给其他子进程及其自己的用户。）同样，限制对文件系统的访问也有其直截了当的理由。鉴于“安全中的简洁是一种美德”，“被攻破的进程无法读取它无法读取的数据，也无法破坏它无法写入的文件”[2 (https://arxiv.org/html/2607.03056#bib.bib2)]。因此，unveil的总体理由可以与其他文件系统完整性解决方案（如NetBSD中基于策略的veriexec子系统[22 (https://arxiv.org/html/2607.03056#bib.bib22)]）相比较。不同之处再次在于，unveil调用直接在源代码中使用。

### II-C采用挑战

然而，也存在实际挑战。由于各种原因，包括知识差距和工作量要求，软件安全技术和特性的采用存在众所周知且持久的挑战[23 (https://arxiv.org/html/2607.03056#bib.bib23)]。尽管情况多年来有所改善，但特别是主动、预防性安全工程技术和特性的采用已被观察到比被动技术（包括处理软件漏洞）的采用更慢[24 (https://arxiv.org/html/2607.03056#bib.bib24)]。一个可能的解释可能与观察结果有关，即许多安全工程活动往往集中在产品发布前的开发后验证上[25 (https://arxiv.org/html/2607.03056#bib.bib25)]。因此，对沙箱技术（包括特别针对pledge、seccomp和unveil）的批评也就不足为奇了[3 (https://arxiv.org/html/2607.03056#bib.bib3),12 (https://arxiv.org/html/2607.03056#bib.bib12),13 (https://arxiv.org/html/2607.03056#bib.bib13)]。尽管有研究，自动化仍然是一个挑战[12 (https://arxiv.org/html/2607.03056#bib.bib12)]，以及其他问题。类似的批评也适用于基于策略的解决方案，例如安全增强型Linux（SELinux）实现[26 (https://arxiv.org/html/2607.03056#bib.bib26)]。特别是在其他开发者需要做这项工作的情况下，据推测很难让他们采用安全技术。调试既困难又耗时。话虽如此，应该注意到类似的观点也更普遍地适用；例如，新应用程序编程接口的采用已被观察到是缓慢的[27 (https://arxiv.org/html/2607.03056#bib.bib27)]。

这些潜在的采用挑战已被OpenBSD开发者隐式承认，他们列出了各种调试工具来帮助开发者采用pledge和unveil[15 (https://arxiv.org/html/2607.03056#bib.bib15),21 (https://arxiv.org/html/2607.03056#bib.bib21)]。话虽如此，BSD操作系统在这方面有优势，因为它们是完整的操作系统，意味着它们有自己的内核和非内核用户空间。因此，采用挑战可能更多地在于通过OpenBSD软件包管理器提供的外部软件。在这方面，有批评指出，特别是对于大型和复杂的软件，采用可能很困难[9 (https://arxiv.org/html/2607.03056#bib.bib9)]。由于本文仅限于OpenBSD不断演进的用户空间，这些关于潜在采用挑战的要点并未得到尽可能全面的研究。尽管如此，一个案例研究（关于“在其自然环境中研究当代现象”[28 (https://arxiv.org/html/2607.03056#bib.bib28), p. 131]）有助于理解pledge和unveil在其自然环境中（即OpenBSD操作系统）被采用的程度。据作者所知，本文也是首次对系统调用的纵向采用进行实证研究。

### II-D研究问题

上述讨论引出了以下四个研究问题（RQs），用于指导实证分析：

- • RQ.1：在OpenBSD的近期历史中，pledge和unveil的采用率如何？
- • RQ.2：软件大小是否影响了采用率？
- • RQ.3：通过pledge经常承诺什么，以及通过unveil经常揭示什么？
- • RQ.4：无论RQ.1的答案如何，各个版本之间的承诺和揭示是否稳定？

通过这些研究问题，本文进一步与大型实证软件进化研究分支交织在一起。在这方面，Linux内核一直是案例研究的热门选择[19 (https://arxiv.org/html/2607.03056#bib.bib19)]。尽管有针对BSD操作系统的案例研究和比较研究[29 (https://arxiv.org/html/2607.03056#bib.bib29),30 (https://arxiv.org/html/2607.03056#bib.bib30),31 (https://arxiv.org/html/2607.03056#bib.bib31),32 (https://arxiv.org/html/2607.03056#bib.bib32)]，包括专门针对OpenBSD的[3 (https://arxiv.org/html/2607.03056#bib.bib3),33 (https://arxiv.org/html/2607.03056#bib.bib33)]，但与涉及Linux和开源软件的研究相比，它们的数量似乎有限。因此，关于OpenBSD新安全特性的案例研究也为实证软件工程知识做出了一个小贡献。

## III材料与方法

### III-A数据

pledge系统调用首次出现在OpenBSD 5.9中，而unveil稍晚一些，在6.4版本中引入[34 (https://arxiv.org/html/2607.03056#bib.bib34),35 (https://arxiv.org/html/2607.03056#bib.bib35)]。因此，数据集（也可在线获取用于复制[36 (https://arxiv.org/html/2607.03056#bib.bib36)）基于从OpenBSD 5.9到7.7的版本。覆盖的时间范围从2016年3月到2025年4月。7.7版本是撰写本文时的最新版本。总共观测了1919个版本。尽管这个数量对于使用正式时间序列方法来说属于边缘情况，但大约十年的日历时间跨度足以回答RQ.1和RQ.4。

存档的（src.tar.gz）源代码树是从一个存档了OpenBSD完整历史的镜像中检索到的。222https://mirror.leaseweb.com/pub/OpenBSD/通过采用相关工作中使用的解析策略[19 (https://arxiv.org/html/2607.03056#bib.bib19)]，数据集是通过逐行处理每个以.c结尾的文件构建的，通过查找pledge和unveil字符串后跟左括号的出现来识别承诺和揭示。排除了OpenBSD源代码树中的distrib、gnu、regress和sysroot目录。这些目录包含附带GNU许可的捆绑软件、回归测试、内核代码和杂项文件。

### III-B度量与测量

测量分析涉及对两个系统调用的调用次数以及这些调用的参数计数。关于后者计数，测量侧重于传递给pledge的第一个参数和传递给unveil的第二个参数。这些将在第IV-C (https://arxiv.org/html/2607.03056#S4.SS3)子节呈现结果时进一步阐述。目前，只需注意传递给pledge的第二个参数被省略，因为几乎所有参数都是NULL值，而传递给unveil的第二个参数涉及授予作为第一个参数提供的路径的权限。