A Measurement Study on the Adoption of Pledges and Unveils in the OpenBSD Operating System
Abstract: The paper presents a longitudinal measurement study on the adoption of the pledge and unveil system calls in OpenBSD. These system calls are used to sandbox programs and libraries. Given a dataset covering 19 releases, many programs and libraries were modified to use the system calls already before their introductions in official releases. The adoption rates have also steadily grown; a linear trend provides a coarse but sensible heuristic. Although particularly programs residing in /usr/bin and /usr/sbin have been modified to use the system calls, the sizes of programs and libraries do not correlate well with the amounts of pledge and unveil system calls invoked. Regarding the pledges made, standard input and output operations have frequently been requested, although the full fine-grained arsenal offered by pledge has generally been utilized in OpenBSD. The same observation is seen in that particularly read operations to given paths have frequently been unveiled. All in all, the measurement results indicate that the adoption of system call minimization and sandboxing techniques is not necessarily as troublesome as has often been discussed in the literature.
Summary
- The paper demonstrates rapid, sustained adoption of pledge and unveil, citing over 700 pledge calls and nearly 300 unveil calls in the latest release.
- The paper employs systematic source code parsing over 19 releases to analyze correlation between system call usage and software size, revealing minimal dependence.
- The paper identifies stable, tailored functional usage patterns of privileges, underscoring the feasibility of OS-level system call minimization.
Empirical Analysis of Pledge and Unveil Adoption in OpenBSD
Introduction
This paper presents a comprehensive longitudinal measurement study of the adoption of the pledge and unveil system calls within the OpenBSD operating system. These system calls implement sandboxing and system call minimization for userland processes by restricting their capabilities at runtime. The analysis is rooted in empirical data captured over 19 OpenBSD releases, covering both programs and libraries maintained directly by OpenBSD developers. Beyond mere adoption metrics, the study investigates the association of adoption rates with software size and characterizes the functional usage patterns of these mechanisms over time.
Background and Motivation
Attack surface minimization is central to contemporary operating system security, often operationalized by constraining available system calls for user processes. OpenBSD’s pledge and unveil system calls embody a paradigm distinct from alternatives like Linux seccomp or FreeBSD capsicum, emphasizing declarative, fine-grained, and source-level restriction of process privileges and filesystem access. Notably, prior academic studies on the empirical uptake of such mechanisms within OS code bases have been sparse, with limited work specifically on OpenBSD (2607.03056).
Pledge allows a process to declare ("promise") the set of system services it will invoke, enforced by the kernel with process termination upon violation. Unveil restricts filesystem access to disclosed paths, enforcing a "least-privilege" file view. Together, they offer explicit and auditable reductions of attack surface and the principle of least privilege, aligned with OpenBSD’s security philosophy.
Despite well-documented security efficacy, practical adoption in real-world systems is frequently perceived as encumbered by complexity, insufficient documentation, or maintainability challenges. The explicit empirical evaluation of OpenBSD’s own progress on this front addresses gaps in both software security engineering literature and measurement-oriented software evolution research.
Methodology
The study utilizes source code snapshots from 19 OpenBSD releases spanning 2016 to 2025, beginning with the introduction of pledge (5.9) and encompassing the introduction and subsequent use of unveil (6.4). Systematic parsing of all .c files within the OpenBSD source—excluding the distrib, gnu, regress, and sys directories—enabled counting of pledge/unveil calls, parameter typologies, and mapping to root directories and program/library granularity. Software size was proxied by .c file counts within subdirectories.
Metrics include:
- Absolute counts of pledge and unveil calls per release and per program/library
- Distributions of promised capabilities (pledge) and unveiled permissions (unveil)
- Correlation analysis between system call deployment and proxy software size
- Trends of parameter usage across the temporal window
Adoption Trajectories
The data show unequivocal evidence of rapid and sustained adoption of pledge and unveil across OpenBSD’s userland. Extensive modification occurred prior to official feature release—indicative of proactive refactoring and cross-release stability (Figure 1).
Figure 1: Longitudinal counts of calls to pledge and unveil across 19 OpenBSD releases, demonstrating sustained, linear growth.
Adoption is not confined to modules intended as exemplars or “trivial” applications; distributions by root installation directory document broad coverage, especially in /usr/bin and /usr/sbin (Figure 2).
Figure 2: Distribution of pledge and unveil calls across OpenBSD root directories, highlighting widespread adoption beyond simple utilities.
The current release (7.7) contains over 700 unique pledge calls and nearly 300 unveil calls, supporting claims that at least 90% of base system processes are sandboxed under a fresh OpenBSD installation.
Software Size and Adoption Patterns
Assessment of whether larger or more complex software exhibits greater system call minimization integration reveals minimal to no correlation. Among the top-25 adopting programs and libraries (Figure 3), usage frequency does not scale with .c file count (software size).
Figure 3: Programs/libraries with highest use of pledge and unveil, revealing that both small and relatively larger components employ system call minimization.
Figure 4: Low correlation coefficients between .c file count and system call deployment, indicating software size is not a primary determinant of adoption.
With correlation coefficients of 0.052 (unveil) and 0.332 (pledge), and even lower values using mean as aggregation, the hypothesis that large code bases struggle disproportionately or are prioritized for minimization is not supported.
Functional Usage and Temporal Stability
The most commonly declared pledge promises and unveil permissions emphasize standard input/output, read, and write operations, but a broad spectrum of more specialized privileges is utilized as well (Figure 5).
Figure 5: Ranked frequency of pledge promises (outer plot) and unveil permissions (inner plot) across the code base, revealing dominance of stdio, rpath, wpath, and cpath.
Unveil permissions exhibit strong emphasis on read-only path access, matching the prevalence of rpath in pledge declarations. Importantly, the relative frequencies of pledge/unveil argument types remain stable over time (Figure 6), demonstrating that adoption involves consistent patterns rather than reactionary or haphazard integration.
Figure 6: Temporal stability in the usage of the most common pledge promises and unveil permissions across releases.
These patterns collectively indicate not only holistic adoption but deliberate tailoring of privileges to fit specific code responsibilities, rather than blanket application of coarse-grained restrictions.
Implications, Future Directions, and Limitations
The comprehensive penetration of pledge and unveil throughout OpenBSD’s userland has several implications. First, it empirically challenges claims that system call minimization is infeasible or prohibitively burdensome at operating system scale. Second, the diversity of utilized privileges suggests that OpenBSD’s model provides sufficient flexibility to adapt to varied application architectures. Finally, the lack of association with software size contests the notion that complexity or large size precludes practical minimization.
However, the study specifically examines code maintained by OpenBSD developers; extrapolation to external packages or to the challenges of maintenance, debugging, and long-term sustainability remains an open question. Direct comparison with Linux seccomp or FreeBSD capsicum is hampered by semantic and implementation differences. The operationalization of complexity and its potential role in the cost of adoption could be strengthened by integrating code churn, commit revert frequency, and explicit complexity measures in future research.
From a theoretical standpoint, the findings support the notion that strong, declarative least-privilege interfaces can, when accompanied by adequate project cohesion, be broadly adopted. Practically, the study suggests POSIX or other standards efforts could consider integrating similar features. Verifying the direct impact on vulnerability or exploit rates awaits further study; mere adoption does not guarantee proportional security benefit.
Conclusion
The pledge and unveil system calls for OS-level sandboxing have undergone widespread and persistent adoption in the OpenBSD base system. Adoption spans both small utilities and larger subsystems, is decoupled from software size, and utilizes the full spectrum of available privileges in a stable, systematic manner. These findings substantiate the feasibility of system call minimization at scale within a cohesive open source project and suggest the transferability of its core approach to other OS contexts, pending further research on maintenance and long-term security impacts.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
A simple explanation of the paper
1) What this paper is about
This paper looks at how a computer operating system called OpenBSD has been adding two safety features named “pledge” and “unveil.” These features help “sandbox” programs—meaning they limit what a program is allowed to do—so that if a program gets hacked, it can’t do much damage.
Think of the operating system as a big building. Every program is a person in the building, and “system calls” are the doors to rooms with special tools. The more doors a person can open, the easier it is for a thief to get into important rooms. “Pledge” is like a promise a person makes: “I will only use these few doors.” “Unveil” is like putting a curtain over most of the building’s map and revealing only the hallways a person is allowed to walk through.
The paper’s purpose is to measure, over about ten years of OpenBSD releases, how much developers actually used these two safety tools and what they used them for.
2) What questions the researchers asked
The paper explores four easy-to-understand questions:
- How quickly and how widely did OpenBSD programs start using pledge and unveil?
- Do bigger programs use these features more than smaller ones?
- Which permissions do programs most often ask for when they “pledge” or “unveil”?
- Have these choices stayed consistent over time?
3) How the researchers studied it
The authors did a “longitudinal” study—like a time‑lapse—across 19 versions of OpenBSD from 2016 to 2025. They downloaded each release’s source code and automatically scanned the C files for the text “pledge(” and “unveil(” to count how often these calls were used.
- “Counting calls” means: How many times programmers added pledge and unveil in the code.
- They also looked at the first setting given to pledge (the “promises,” such as “stdio” for basic input/output) and the permission letters given to unveil (like “r” for read).
- To estimate program size, they counted how many C source files a program has, then checked whether bigger programs used more pledge/unveil calls.
- They grouped programs by where they live in the operating system (for example, /usr/bin or /usr/sbin) to see where adoption was strongest.
In short, they measured what was used, where, how often, and how this changed over time.
4) What they found and why it matters
Here are the key results:
- Adoption grew early and steadily: Many programs started using pledge and unveil even before the features officially appeared in released versions. Over time, usage kept growing in a roughly straight-line trend. In the latest version studied (7.7), there were 700+ pledge calls and nearly 300 unveil calls across the system.
- Widespread across core tools: Lots of commonly used system programs, especially in /usr/bin and /usr/sbin, use these features. This shows pledge and unveil aren’t just for tiny or “toy” tools; they’re used broadly in important parts of the system.
- Size doesn’t predict usage: Bigger programs did not necessarily use pledge/unveil more than smaller ones. In other words, there wasn’t a strong link between program size and how many times these safety calls were used.
- Most common permissions are simple and practical: With pledge, the most frequent “promises” were for basic input/output (“stdio”) and reading/writing/creating files (“rpath”, “wpath”, “cpath”). With unveil, the most common permission was “r” (read access to certain paths). Even so, developers used a wide variety of options—showing the tools are flexible.
- Stable choices over time: The kinds of promises and unveil permissions stayed fairly stable across releases, with some gentle growth in the most basic ones.
Why this matters: Many people think adding security restrictions is hard and slows developers down. These results suggest that, at least in OpenBSD’s own code, using simple, focused tools like pledge and unveil can be done widely and consistently over time. That’s encouraging for making systems safer in practice.
5) What this could mean going forward
- For security: By narrowing what programs can do and what files they can see, the “attack surface” (the number of ways an attacker can break in) gets smaller. If a program is tricked into misbehaving, the damage is limited because the operating system will block off-limits actions.
- For developers and other systems: This study suggests that simpler, well‑designed sandboxing tools can be adopted across many programs, not just small ones. Other operating systems might learn from this approach or work toward common standards so more software can benefit.
- For future research: The study measured adoption, not whether it directly reduced hacks. Next steps could connect these adoption trends to real-world security outcomes, and explore how much maintenance effort is needed to keep these restrictions up-to-date.
In short, the paper shows that OpenBSD developers have been steadily and broadly using pledge and unveil to lock down programs, and they’ve done so in a way that looks practical and sustainable. It’s a hopeful sign that smart, simple rules can make everyday software safer.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a concise list of what remains missing, uncertain, or unexplored in the paper, framed to guide actionable future research.
- External validity beyond OpenBSD base: no comparative longitudinal analysis with Linux seccomp or FreeBSD capsicum; unclear whether findings generalize across OSes or sandboxing models.
- Ports/packages ecosystem omitted: adoption and challenges in third‑party software distributed via OpenBSD ports were not measured longitudinally.
- Security impact unmeasured: no evidence on whether pledge/unveil adoption correlates with fewer exploits, reduced exploitability, or lower severity of security incidents.
- Developer effort and maintenance cost unknown: the study does not quantify the engineering effort, debugging time, breakage rates, or long‑term maintenance burden attributable to pledge/unveil.
- Policy correctness and minimality unassessed: no analysis of whether promises and unveils are over‑permissive, under‑permissive, or minimally sufficient for least privilege.
- Runtime effectiveness unmeasured: absence of dynamic measurements (e.g., policy violation rates, kernel kills, false positives/negatives) to validate that static calls are exercised as intended.
- Performance overhead not evaluated: no micro/macro benchmarking to assess latency/throughput impacts of pledge/unveil on typical workloads.
- Per‑program evolution is opaque: lacks longitudinal diffs of policy changes within individual programs (e.g., how promise sets evolve across releases and why).
- Granularity of adoption not linked to runtime coverage: counts of static call sites are not weighted by process prevalence or execution time in deployed systems.
- Drivers and barriers of adoption unexplored: no qualitative or quantitative analysis of maintainers’ decision processes, tooling use, or organizational factors enabling rollout.
- Automation and tooling effectiveness untested: the impact of OpenBSD debugging/tools on adoption speed, policy quality, and correctness is not assessed.
- Unveil path analysis omitted: the study does not analyze which file paths are unveiled or categorize them (e.g., config, secrets, sockets), missing insight into resource exposure patterns.
- Execpromises (second pledge argument) ignored: even if rare, the cases where non‑NULL execpromises are used were not characterized.
- Order/timing semantics unexamined: no study of pledge/unveil placement in process lifecycles (pre/post‑fork/exec), privilege‑separation phases, or multi‑call sequences per program.
- Libraries vs binaries not disentangled: methodology based on subdirectories obscures differences in adoption patterns and responsibilities between libraries and executables.
- Size/complexity proxies are crude: reliance on number of .c files; no use of more informative metrics (e.g., cyclomatic complexity, code churn, dependency depth, binary size).
- Not normalized by system growth: adoption counts are not scaled by growth in codebase size or number of programs, potentially overstating trends.
- Limited time‑series modeling: only linear trend heuristics; no interrupted time series, changepoint, or diffusion modeling to detect adoption phases or structural breaks.
- Release‑only sampling is coarse: excludes fine‑grained VCS history, limiting the ability to pinpoint adoption events, reversions, or bursts tied to specific commits.
- Potential parsing inaccuracies: simple text matching may include false positives (comments/strings) or miss macro‑wrapped calls; no AST‑level validation reported.
- Language and build coverage gaps: only .c files considered; code in other languages or generated sources may host pledge/unveil invocations and remain uncounted.
- Mapping from directories to artifacts is imprecise: multiple binaries/libraries per subdirectory confound per‑program adoption counts; installed artifact mapping is needed.
- Overlapping code duplication not controlled: shared utilities or copied modules may inflate call counts without reflecting independent adoption decisions.
- Directory‑level comparisons not normalized: counts per directory are not normalized by number of programs or size, making cross‑area comparisons difficult.
- Stability of promises lacks context: observed stability across releases is not linked to upstream changes, API evolution, or platform events that might drive shifts.
- Interactions with other mitigations unexplored: no analysis of how pledge/unveil interplay with ASLR, WX, or other OpenBSD hardening features.
- Standardization and portability unanswered: feasibility and implications of POSIX‑style standardization or Linux ports (pledge-on-Linux) remain open.
- Risk‑based prioritization unstudied: no evidence on whether high‑risk components were preferentially sandboxed or how risk assessments guided rollout.
- Failure modes and recoverability unknown: lacks data on how pledge/unveil‑induced failures are detected, logged, and mitigated in operational environments.
- Misuse patterns not characterized: no taxonomy or prevalence of common pitfalls (e.g., forgetting to tighten after initialization, overbroad promise strings).
- Dependency effects unmeasured: how library‑level pledge/unveil affects downstream consumers and whether it constrains API usage is not assessed.
- Threat model alignment unclear: no validation that chosen promises/unveils align with documented threat models for each component.
- Reproducibility details could be stronger: dataset/build scripts do not document comment stripping, macro expansion, or handling of conditional compilation, limiting replication fidelity.
Practical Applications
Immediate Applications
Below are concrete ways practitioners can use the paper’s findings today.
- OpenBSD base-system hardening coverage dashboard
- Sector: software, security engineering
- What: Use the paper’s release-by-release counts and directory breakdowns to build a “pledge/unveil coverage” dashboard for the OpenBSD src tree (and local forks), highlighting binaries in /usr/bin and /usr/sbin with no or partial adoption.
- Tools/workflows: Simple parsers (like the paper’s), badge in CI for per-program coverage, nightly HTML report.
- Assumptions/dependencies: Access to source; consistent parsing of C sources; organizational agreement on target coverage thresholds.
- Developer starter kit for common pledge/unveil patterns
- Sector: software
- What: Publish ready-to-paste snippets/templates for the most frequent promises and permissions observed (e.g., "stdio", "rpath/wpath/cpath", "inet", "tty"; unveil "r" for path reads), including ordering guidelines (pledge early, tighten later; unveil paths before access).
- Tools/products: Header-only helpers, man-page-aligned cheatsheets, example PRs for popular utilities.
- Assumptions/dependencies: Codebases can be modified; test suites exist to catch regressions.
- CI/CD guardrails for OpenBSD-targeting projects
- Sector: software, DevSecOps
- What: Add lint rules that flag binaries without pledge/unveil in main code paths; run dynamic traces (ktrace/kdump) in tests to verify the process keeps its promises and that unveiled paths are sufficient.
- Tools/workflows: Static checks in pre-commit; test jobs that fail on SIGKILL from broken promises; dashboards of violations across releases.
- Assumptions/dependencies: Adequate test coverage; access to OpenBSD runners; willingness to gate merges on security checks.
- Ports/package triage playbook not biased by size
- Sector: software ecosystems (OpenBSD ports, downstream distros)
- What: Prioritize both small and large programs for adoption since size correlates poorly with usage; start with userland utilities akin to /usr/bin and /usr/sbin where adoption was strongest.
- Tools/workflows: Backlog with tags “pledge first,” “unveil first,” suggested patch templates by program category (CLI, daemon, network client).
- Assumptions/dependencies: Maintainer buy-in; upstream acceptance when patching third-party code.
- Enterprise hardening KPIs and policy mapping
- Sector: enterprise IT, compliance
- What: Track % of in-house OpenBSD daemons using pledge/unveil as a security KPI; map this to attack-surface minimization requirements (e.g., EU CRA “essential requirements” and ATT&CK mitigations referenced by the paper).
- Tools/workflows: Policy checklists in SSPs, quarterly KPI reviews, exception handling for legacy services.
- Assumptions/dependencies: Compliance teams accept system-call minimization as a control; audit evidence (logs/config) is retained.
- Procurement and vendor requirements for appliances
- Sector: networking/security appliances, finance/healthcare IT procurement
- What: Add RFP/RFI clauses requiring pledge/unveil usage in vendor software shipped on OpenBSD-based appliances; ask for a per-binary “pledge/unveil bill of practices.”
- Tools/products: Contract language templates; vendor self-attestation forms; spot checks via binary/source review.
- Assumptions/dependencies: Vendors target OpenBSD or can show equivalent controls on other OSes; legal teams endorse the clauses.
- Teaching modules and labs using the open dataset
- Sector: academia, education
- What: Use the paper’s dataset to teach longitudinal measurement, secure-by-construction OS features, and reproducible research; assign labs to add pledge/unveil to a small C utility and measure impact.
- Tools/workflows: Course notebooks, automated graders that validate promises/permissions, before/after syscall trace comparison.
- Assumptions/dependencies: Students have OpenBSD VMs; dataset access (Zenodo) and scripts are maintained.
- Operational audits and incident blast-radius reduction
- Sector: IT operations, SRE
- What: Audit local daemons for pledge/unveil coverage; review logs for kernel-enforced kills due to promise violations; prioritize refactoring services that touch sensitive paths but only need read access (aligning with frequent r/rpath patterns).
- Tools/workflows: Scheduled audits; log monitors for pledge violations; runbooks to progressively tighten promises.
- Assumptions/dependencies: Logging/monitoring in place; staff trained to iterate safely without service outages.
Long-Term Applications
These leverage the study’s insights but require additional research, standardization, or engineering.
- POSIX-aligned standardization of syscall-minimization primitives
- Sector: policy/standards
- What: Initiate a standards effort to define a cross-UNIX API for runtime syscall and filesystem minimization (pledge/unveil-like), with normative mappings to Linux (seccomp/landlock), FreeBSD (capsicum), etc.
- Tools/products: API spec drafts; conformance test suites; reference adapters.
- Assumptions/dependencies: Multi-stakeholder buy-in; semantic differences reconciled; legal compatibility.
- Automated policy synthesis from traces
- Sector: software tooling, cloud-native security
- What: Tools that learn minimal pledge strings and unveil path-permissions from dev/test/production traces, then propose patches and CI verifiers.
- Tools/products: ktrace/ptrace-based profilers; diff-based “tightening” suggestions; regression testers.
- Assumptions/dependencies: Representative workloads; safe generalization from traces; developer review loop to prevent overfitting.
- IDE/code-intelligence assistants for pledge/unveil
- Sector: software engineering tools
- What: Language-server plugins that infer needed promises/permissions from imports, syscalls, and path usage, and surface inline recommendations and fix-its.
- Tools/products: LSP extensions; callgraph analyzers; training data from the paper’s longitudinal corpus.
- Assumptions/dependencies: Static analysis precision on C code; low false positives to ensure developer trust.
- Formal contracts linking program preconditions to promises
- Sector: academia, verification
- What: Extend design-by-contract to include “pledge/unveil contracts,” with static checks that code paths respect declared capabilities; runtime monitors serve as last-resort enforcement.
- Tools/products: Annotations/macros; model checking/abstract interpretation; proof-carrying builds.
- Assumptions/dependencies: Annotated codebases; tractable verification for performance-critical code.
- Evidence-based risk reduction studies
- Sector: academia, policy, security assurance
- What: Correlate adoption trajectories with vulnerability and exploit data to quantify risk reduction; inform certification schemes and regulatory guidance.
- Tools/workflows: Time-series analyses; matched-control studies; disclosure/exploit feeds integration.
- Assumptions/dependencies: High-quality vulnerability/exploit datasets; careful confounder control (the paper notes causality is open).
- SXBOM: System-call Exposure Bill of Materials
- Sector: software supply chain
- What: Extend SBOMs with machine-readable summaries of promised syscalls and unveiled permissions per binary, enabling downstream policy checks and runtime attestation.
- Tools/products: SBOM schema extensions; build-step generators; verifiers in admission controllers.
- Assumptions/dependencies: Community acceptance; secure build pipelines to prevent spoofing.
- Cross-OS policy translators
- Sector: software, cloud/container security
- What: Translate common pledge/unveil patterns into Linux seccomp profiles, Landlock rules, or FreeBSD capsicum capabilities to bring OpenBSD lessons to containers and services elsewhere.
- Tools/products: Mapping libraries; CI checks that validate parity; starter profiles for common services.
- Assumptions/dependencies: Imperfect semantic equivalence; continuous maintenance as kernels evolve.
- Enterprise attack-surface observability across fleets
- Sector: enterprise security operations
- What: Unified dashboards that ingest “capability-minimization signals” from mixed OS fleets (pledge/unveil, seccomp, AppArmor/SELinux, capsicum) to track adoption, drift, and exceptions.
- Tools/products: Telemetry collectors; posture management; exception workflows.
- Assumptions/dependencies: Endpoint agents; normalized schemas for disparate mechanisms; privacy considerations.
- Hardened embedded/edge deployments
- Sector: networking, energy/ICS, robotics/IoT
- What: Adopt OpenBSD with pledge/unveil for routers, firewalls, gateways, and HMIs; constrain daemons to the frequent minimal sets (stdio + read-only paths) demonstrated to work widely.
- Tools/workflows: Vendor BSPs with pledge/unveil baselines; factory test harnesses that verify capability budgets.
- Assumptions/dependencies: OpenBSD suitability for the device; supplier cooperation; long-term maintenance of policies.
- Developer usability and maintenance cost research
- Sector: academia, developer experience
- What: Longitudinal studies on debugging effort, churn, and reverts when tightening promises, producing guidelines that reduce “maintenance nightmare” risks cited in prior work.
- Tools/workflows: Mining software repositories; controlled user studies; decision guides for when to tighten vs split processes.
- Assumptions/dependencies: Access to repo histories and developers; consistent operational metrics.
Each application builds directly on the paper’s core findings: steady, broad adoption; effectiveness across both small and large programs; frequent reliance on a compact, reusable subset of promises/permissions; and relative stability of usage patterns across releases. Feasibility hinges on codebase modifiability, reliable testing, and, for cross-OS goals, reconciling semantic differences among sandboxing mechanisms.
Glossary
- attack surface: The set of accessible system resources or interfaces (here, system calls) that an attacker could potentially exploit. "Attack surface minimization is a classical security engineering technique."
- attack surface minimization: The practice of reducing exposed functionality (e.g., available system calls) to limit potential attack vectors. "the terms attack surface and attack surface minimization are restricted to system calls"
- capsicum: A capability-based sandboxing framework in FreeBSD that limits process privileges via fine-grained capabilities. "the capability-based capsicum implementation in FreeBSD"
- cpath (pledge promise): A pledge permission that allows creating or altering filesystem paths (e.g., file creation/renaming). "rpath, wpath, and cpath parameters"
- dropping privileges: Reducing a process’s privileges from elevated (e.g., root) to a less-privileged user after startup. "both dropping privileges and privilege separation benefit from the use of the pledge system call"
- execve: A Unix system call that executes a program, replacing the current process image. "processes (proc and execve), and many others."
- inet (pledge promise): A pledge permission that allows using Internet sockets. "including promises about sockets (inet), terminals (tty), processes (proc and execve), and many others."
- POSIX: A family of standards that define a common operating-system interface and compatibility. "The Portable Operating System Interface (POSIX) set of standards might be something to consider in this regard."
- pledge: An OpenBSD system call to declare a process’s allowed classes of operations; violations cause the kernel to terminate the process. "introduced a new pledge system call for minimizing attack surfaces related to system calls."
- privilege separation: Splitting a program into components so only minimal parts run with elevated privileges. "both dropping privileges and privilege separation benefit from the use of the pledge system call"
- proc (pledge promise): A pledge permission that allows process-management operations (e.g., signals, forking). "processes (proc and execve), and many others."
- ptrace: A debugging/tracing interface that allows one process to observe and control another; often a security concern. "maintenance problems with some specific system calls, such as ptrace in Linux"
- r (unveil permission): An unveil permission flag granting read access to unveiled paths. "over 40% of the calls to unveil have used the r permission"
- rpath (pledge promise): A pledge permission that allows reading from filesystem paths. "rpath, wpath, and cpath parameters"
- sandboxing: Isolating software to restrict its capabilities and limit damage from compromise. "These system calls are used to sandbox programs and libraries."
- seccomp: A Linux mechanism that filters system calls to sandbox processes. "the seccomp sandboxing solution in Linux confirmed the many difficulties"
- SELinux: A Linux security module enforcing mandatory access control policies. "Security-Enhanced Linux (SELinux) implementation"
- stdio (pledge promise): A pledge permission that allows standard input/output operations. "Only the stdio and r parameters have seen visible growth,"
- systrace: A historical OpenBSD policy-based tool that mediated system calls via per-policy rules. "systrace utility from the early 2000s"
- system call minimization: Restricting the set of system calls a process can invoke to reduce attack surface. "the adoption of system call minimization and sandboxing techniques"
- tty (pledge promise): A pledge permission that allows terminal device interactions. "including promises about sockets (inet), terminals (tty), processes (proc and execve), and many others."
- unveil: An OpenBSD system call that restricts a process’s filesystem view to specified paths with explicit permissions. "unveil was introduced a little later, in the 6.4 release"
- userland: The non-kernel part of an operating system where applications execute. "sandboxing userland processes is a common technique"
- veriexec: A NetBSD subsystem that enforces file integrity policies. "the policy-based veriexec subsystem in NetBSD"
- wpath (pledge promise): A pledge permission that allows writing to filesystem paths. "rpath, wpath, and cpath parameters"
Collections
Sign up for free to add this paper to one or more collections.