Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

Mahya Soleimani Jadidi

and Jonathan Anderson

Department of Electrical and Computer Engineering, Memorial University of Newfoundland, NL, Canada

Keywords:

Application Sandboxing, System Call Filtering, Capability-Based Sandboxing, Application

Compartmentalization.

Abstract:

In computer security, the principle of least privileges or denial by default is a practical approach to mitigate the

risk against potential attacks. However, providing least-privileged applications is a challenge without source

code modiﬁcation, system privilege, or conﬁguration changes. In this paper, we introduce Leash, a transparent

application sandboxing supervisor for Unix systems designed based on FreeBSD’s Capsicum framework.

Leash provides required resources to programs based on sandbox restrictions and policies predeﬁned by the

user without requiring root privilege. The approach is transparent to the code and the user, eliminating the

need for any source code modiﬁcation and deep knowledge about the underlying security framework. We

evaluated this system by sandboxing a set of widely used Unix utilities and real-world installer scripts. Leash

is designed to be expandable for becoming a general-purpose sandboxing service for Unix. Our evaluations

show that the system achieves robust security while maintaining efﬁcient performance.

1 INTRODUCTION

The principle of least privilege, also known as "deny

by default", is a fundamental strategy for mitigat-

ing security risks. For applications exposed to un-

trusted networks, enforcing least-privilege execution

enhances both the security of the application and the

underlying host system. However, implementing this

principle in applications is challenging, especially

without extensive code modiﬁcations or system con-

ﬁguration changes.

In Unix, installing many applications involves

downloading ﬁles and executing shell scripts, often

with elevated privileges (i.e., root). This includes de-

velopment tools, libraries, and system management

utilities. Installer scripts are attractive targets for ma-

licious actors, particularly in open-source software.

Thus, protecting users and developers from harmful

installation scripts and supply chain attacks is essen-

tial.

In this paper, we present Leash, a system designed

for transparent sandboxing of applications in Unix en-

vironments without requiring root privilege. Leash

offers a lightweight sandboxing mechanism, that runs

an application with least privileges. It is built on Cap-

sicum, a sandboxing framework for FreeBSD. Leash

https://orcid.org/0000-0002-7897-410X

https://orcid.org/0000-0002-7352-6463

establishes a user-level sandboxing environment with

Capsicum capabilities, granting only the essential ac-

cess privileges to the executing process. Leash pro-

vides two levels of transparency:

• Code transparency: Leash does not require modi-

fying the target’s source code.

• User transparency: Leash does not require users

to have in-depth knowledge of Capsicum.

This paper is organized as follows: Section 2 pro-

vides essential background information. Section 3

discusses key challenges in designing a transparent

sandboxing system. Section 4 describes the internal

design, including the framework and policies. Section

5 outlines our evaluation methodology and discusses

key ﬁndings. Related work is reviewed in section 6.

Future work is covered in section 7, and section 8

summarizes this study, including the conclusions.

2 BACKGROUND

Leash is designed based on FreeBSD, which features

a capability-based framework in its kernel called

Capsicum (Watson et al., 2010). Capabilities are un-

forgeable tokens of authority that authorize process

access to resources (Fabry, 1974; Dennis and van

Horn, 1975; Anderson, 1972).

542

Jadidi, M. S. and Anderson, J.

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix.

DOI: 10.5220/0013186700003899

In Proceedings of the 11th International Conference on Information Systems Security and Privacy (ICISSP 2025) - Volume 2, pages 542-551

ISBN: 978-989-758-735-1; ISSN: 2184-4356

In capability-based systems, capabilities are tied

to resources, such as ﬁles. They are also known as

object capabilities. Different processes can have dif-

ferent access rights to the same resource. While pro-

cesses can pass capabilities to one another, they can-

not elevate them. Capabilities are unforgeable, allow-

ing the platform or kernel to verify their validity and

prevent unauthorized changes. So, capability-based

systems can enforce the principle of least privilege,

enabling ﬁne-grained, ﬂexible, and dynamic permis-

sion management.

2.1 Capsicum

In Capsicum, capabilities are implemented in the

structure of ﬁle descriptors that reference system re-

sources. In Capsicum’s capability mode, entered by

calling cap_enter(), access to global namespaces

will fail. Processes can only access resources for

which they have capabilities. This restriction will be

applied to the running process and its further descen-

dants.

Capsicum has three categories of system calls:

disallowed functions, conditionally allowed func-

tions, and allowed functions. System calls that try

to gain new access to global namespaces of the sys-

tem, such as open(2), connect(2), mkdir(2), and

wait4(3), are all disallowed. Conditionally allowed

functions are safe functions that can gain unsafe privi-

leges under some circumstances. For example, calling

open(2) with AT_FDCWD set as the ﬁle descriptor tries

to open a ﬁle in the current working directory.

Capsicum offers a secure, restricted environment

to enhance application safety. However, adapting to

Capsicum’s sandbox requires signiﬁcant changes to

source code. Developers must replace unsafe global

namespaces access with least-privileged ones, which

also requires in-depth knowledge of the operating sys-

tem and Capsicum. Section 4 outlines our approach in

addressing these challenges, and describes how Leash

balanced security and functionality to enable more ap-

plications to run safely within Capsicum’s sandbox.

2.2 Linux Capabilities

Linux uses the term "capability" to refer to dis-

tinct units of privilege, which subdivide the tradi-

tional superuser (root) privileges into a more gran-

ular model. This allows root users to be granted

different levels of access to critical system re-

sources (Linux man-pages project, 2024; Linux man-

pages project, 2022). For example, capabilities like

CAP_AUDIT_READ, CAP_KILL, and CAP_CHOWN enable

a process to read audit logs, terminate other pro-

cesses, and change ﬁle ownership, respectively. Set-

ting Linux capabilities needs root privilege. This is

an entirely distinct concept from the object capabil-

ities described above, which refer to individual ob-

jects, such as ﬁles, and do not require root privilege to

use.

3 CHALLENGES IN DESIGNING

SANDBOXING SYSTEMS

Designing a sandboxing system is challenging. As

the primary concern, the sandboxing system should

isolate the target program by making an adequately

conﬁned environment that is not circumventable. As

described in section 6.1, existing sandboxing tools

are either not capable of providing such security or

need invasive modiﬁcations and complicated conﬁgu-

rations. Many existing tools and OS features provide

isolation by restricting the program to a speciﬁc ﬁle

system hierarchy. However, ﬁle system restriction is

not enough for sandboxing applications that can ac-

cess other resources, such as the network.

Many existing applications have not been de-

signed with security in mind. Securing such applica-

tions with existing sandboxing features is either im-

possible or needs modiﬁcations on the source code,

which is a challenge for those with massive code

bases. Hence, transparent sandboxing is required.

Here are the most important problems we resolved

during the design and implementation of Leash:

1. Process management: The target process should

be able to fork, execute, and wait for its descen-

dants. The signiﬁcant point is that the forked

or executed processes should also operate in the

sandbox mode. The challenge is that the super-

visor cannot control the target’s descendants be-

cause they are not processes forked by the super-

visor directly. However, the supervisor can be in-

formed of such function calls to prepare for future

requests and an under-control environment. Sec-

tion 4.1 explains more details about this issue and

our solution to control it.

2. Remote connections: One challenge in control-

ling the target’s connections is the complexity of

connecting to remote servers, such as connect-

ing to the internet. DNS resolving and internet

communications can take more time, and manag-

ing TCP/IP communication should be handled on

the server side. The inter-process communication

(IPC) between the supervisor and the target pro-

cess should be carefully designed to take these

considerations into account.

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

543

3. Circular dependencies in GNU Standard C Li-

brary (libc): in section 4.4, we described how we

handled transparent behaviour changing through

function interposition. However, the design of an

interposition technique can be limited based on

various reasons. One of these challenges is the

existence of circular dependencies in the targeted

set of functions.

4. Process context limitations: Each process has a

distinct context and a set of environment vari-

ables, which may be inherited from its parent pro-

cess. One management problem for the supervisor

process is the changes that happen to this context,

such as changing the current working directory or

re-initialization of global variables that happens

after calling exec() functions. The supervisor

process needs to be updated about these changes

to update the assumptions for further required

decision-making. We handled these cases in the

interposition library described in section 4.4.

4 DESIGN AND

IMPLEMENTATION

In this section, we explain the internal design of

Leash, and development challenges. Figure 1 shows

an abstraction of Leash’s main modules integrated to

form a system for executing the client program in

Capsicum’s sandbox mode. Our design is divided into

four main modules: the supervisor server, the policy

management module, the command handler, and the

interposition library.

The supervisor process calls the policy manager

to initialize the policies deﬁned for the client pro-

gram speciﬁcally. The loaded deﬁnitions will be used

to provide necessary environment variables and re-

sources, including pre-loaded ﬁles and libraries, prior

to executing the target(client) program. The super-

visor establishes an IPC

mechanism between itself

and the client for further expected communications.

Finally, the supervisor executes the client program in

the sandbox mode. From this point on, every disal-

lowed function will be either interposed and proxied

to the supervisor for decision-making or fail due to

capability violations.

4.1 Supervisor Server

The main thread of the supervisor process is responsi-

ble for providing required environment variables, pre-

opening the necessary libraries and a pre-established

Inter Process Communication

Figure 1: Leash’s different modules and their integration.

connection for communication between the supervi-

sor and the client processes, loading the policies, and

serving commands proxied to the command handler

threads. Figure 2 demonstrates this procedure.

After the supervisor fetches all the required infor-

mation for executing the target program, it forks. The

parent process continues to initiate a server thread,

and the child process goes on and enters the sandbox

mode by calling cap_enter() and executes the target

program. From this point on, every disallowed func-

tion will be either interposed or failed. The disallowed

system calls that are not supported in the current de-

sign will fail due to capability violations. Those sup-

ported will be interposed by the interposition library,

which determines whether to wrap or proxy them. Ta-

ble 1 lists all the supported system calls in the current

design. The proxied requests will be considered as

commands, described in section 4.2.

The server can handle parallel commands as

demonstrated in ﬁg. 2. The reason is that the client

process can fork in capability mode, and the de-

scendants are as restricted as their parent processes.

The supervisor server initializes a new connection

and command handler for each new process. Hence,

Leash can support the target and its descendants sep-

arately, also handles process management requests.

4.2 Command Handler

When the interposition library intercepts a disallowed

function call, it will be proxied to the Supervisor

Server if it cannot be handled on the client’s side. We

refer to a proxied call as a command delegated to the

server. The Command Handler module extracts a new

command from the received information. To manage

the request, the newly made command checks the re-

quest with the Policy Manager module, interacts with

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

544

Figure 2: The supervisor multi-threaded request handling.

the user if needed, and will do the changes required

on behalf of the client process if:

1. The request does not conﬂict with any of the pre-

deﬁned policies.

2. The user allows the program to proceed if asked.

When the command is resolved and done, the out-

put will be returned to the client as feedback, and the

serving thread will be prepared to handle the follow-

ing probable command. The supervisor process does

not change the functionality of received commands

but may update policies based on served requests.

4.3 Policy Management

Leash is designed to be an interactive system de-

pending on how it is speciﬁed by the user as poli-

cies. The policies are meant to be deﬁned in a ﬁle

written in UCL format (UCL Documentation, 2014).

Leash loads the policy ﬁle, deﬁnes the required envi-

ronment variables, and pre-opens necessary libraries

before executing the target program in the sandbox.

The policy ﬁle is expected to include three main

sections for accessing pathnames, networking, and

system control requests. These sections should be la-

belled as path, net, and sysctl, respectively. Each sec-

tion of the policy contains the resources that are ad-

dressed by a unique name, such as an absolute address

to a ﬁle. The minimum required access privileges

are speciﬁed following the resource name. When a

request is received from the client process, the be-

haviour will be determined based on the loaded poli-

cies. Each section should include an entry labelled as

"others", which determines the behaviour of the sys-

Listing 1: Sample policy speciﬁcation for sandboxing

curl(8) by Leash.

paths {

" ./ curl_cmd.sh" :

"/dev/ crypto ":

"/ usr / bin / curl " : open|read;

others : ask;

}

net {

"172.217.13.100": connect ;

others : ask;

}

sysctl {

"net . inet . ip . forwarding": read ;

"hw.cachesize": read ;

others : deny;

}

tem in case the resource is not listed in the policy ﬁle.

Hence, we can deﬁne different default actions for cat-

egories of resources. When the target process tries to

access to unspeciﬁed resources, the system behaves

based on the policy deﬁned for "others" in the corre-

sponding section, as explained below:

• ALLOW: The supervisor allows the command to

proceed with the command.

• DENY: The supervisor denies the command and

returns a failure message to the target process.

• ABORT: The supervisor kills the client process.

• ASK: The supervisor asks the user if the request

is allowed to proceed.

Listing 1 includes a sample used for curl(8) command

to download a ﬁle. At the current state, we need to ad-

dress every single required pathname, explicit IP ad-

dresses, and system control variable names. However,

as described in section 7, one of the future work to do

is making policy deﬁnition more convenient in Leash.

4.4 Function Interposition

The interposition library is one of the resources pro-

vided by the supervisor process for the target pro-

gram. The supervisor sets the LD_PRELOAD environ-

ment variable to address the interposition library. By

setting the LD_PRELOAD environment variable, the pri-

ority of the runtime linker (RTLD) for resolving the

functions changes. So, in the procedure of function

resolving, the pre-loaded library will be considered

ﬁrst. This mechanism provides an opportunity for in-

tercepting disallowed functions in Capsicum’s capa-

bility mode at runtime. In the interposition library,

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

545

disallowed functions will be replaced by either a safer

version or a proxy function. The proxy functions send

the call information as a command to the supervisor

and extract the result from its response. The interpo-

sition library returns all the expected results and data

required to maintain the functionality of the function

calls and does not change the functionality or returned

data.

5 EVALUATION

In this section, we describe our methodology and ob-

served results of evaluating the behaviour and perfor-

mance of Leash on real-world examples. We selected

the installer script of Ruby Version Manager(RVM)

as our primary target (RVM, 2009). To install RVM,

the user needs to download the installer script and ex-

ecute it using Bash(1) command, as recommended

by the providers. To succeed, every command the

script calls should inevitably be sandboxed. There-

fore, along with RVM’s installer script, we sandboxed

other utilities including Curl, Fetch, Gtar, and Gzip.

Moreover, 21 of other Unix’ simple commands were

sandboxed as shown in Table 3.

5.1 Platform

Leash is designed and implemented on FreeBSD

13.2-RELEASE as the base OS. However, to achieve

our objectives, we applied some modiﬁcations to the

OS source code, including the kernel. We added

the system call wait6(2) to the allowed functions

in capability mode for the cases where it is called

on any child processes. The evaluations were done

on an amd64-based machine with an 8-core CPU

of the model Intel(R) Xeon(R) CPU E3-1240 v5 @

3.50GHz. To obtain the actual time taken for the ex-

ecuted commands and the memory usage, we used

FreeBSD’s time(1) and ps(1) commands.

5.2 Discussion

As mentioned, to install RVM in the sandbox, we

sandboxed all the utilities this installer called. To

achieve this goal, we interposed all the disallowed

functions called by the installer scripts or the cor-

responding commands, which resulted in the system

calls categorized in Table 1. Along with the main sys-

tem calls, their other versions that were limited in ca-

pability mode needed to intercept. These versions in-

clude internal deﬁnitions of the disallowed functions

such as _open(), and the versions that are usually

Table 1: Interposed system calls for sandboxing RVM’s in-

staller script and the commands it called.

System calls

Purpose

Main Version Other Versions

File System

Access

open()

stat()

statfs()

readlink()

mkdir()

chdir()

eaccess()

unlink()

rename()

utimes()

chmod()

symlink()

openat(), _open()

fstatat(), lstat()

mkdirat()

fchdir()

eaccessat()

unlinkat()

_rename()

utimensat(), _utimes()

fchmodat(), _chmod()

symlinkat()

System Control sysctl() __sysctl()

Process Management

execve()

fork()

wait4()

_execve()

vfork(), _fork()

waitpid(), _wait4()

Networking connect() _connect()

allowed with some exceptions such as openat(2)

called with AT_CWDFD as the ﬁrst argument.

The performance overhead added by executing

programs under Leash is directly related to the num-

ber of intercepted system calls, especially those prox-

ied to the server. So, the interposition library will add

most of the overhead. This overhead can increase de-

pending on the functionality of the target program.

For example, remote connections or massive manipu-

lations on the ﬁle system can result in more than one

intercepted system call and higher overhead. How-

ever, our observations show that this overhead is prac-

tically acceptable and tolerable.

Tables 2 and 3 lists applications and Unix com-

mands executed in Leash’s sandbox. Table 2 sepa-

rates the heavier applications in terms of the volume

of calls, interaction with the system, and longer exe-

cution time and provides more details about the ob-

served performance overhead. Table 3 demonstrates

the commands that are lighter, and their execution

time and overhead were at the scale of milliseconds.

The chart presented in ﬁg. 3 compares the perfor-

mance of the native command vs. the sandboxed ex-

ecution. Although the user cannot sense the sand-

boxing overhead on these utilities, our measurements

show that the slowdown that happened to them by

sandboxing is more signiﬁcant than the applications

listed in Table 2. This observation shows that the cost

of running the supervisor program, runtime interposi-

tion, proxying commands, and supervisor command

handling is more observable with fewer system calls.

While in programs with larger code bases and more

functionalities, the cost of allowed function pervades

the sandboxing overhead.

The most time-consuming mode of Leash is the

one in which every single disallowed function will

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

546

Command Name

Time (ms)

mkdir

mktemp

date

uname

chmod

chown

which

cat

file

grep

find

sort

tee

awk

head

stat

sed

xargs

Sandboxed Native

Figure 3: Unix utilities executed in Leash’s sandbox and

their performance overhead.

Table 2: The performance of the sandboxed applications

and utilities under Leash’s supervision.

Average Time

(Second)

Application

Interposed

System Calls

Original Sandboxed

Slowdown

RVM 17433 5.68 6.25 10%

curl 31 0.30 0.35 16%

fetch 22 0.24 0.25 4.17%

gtar 11055 0.30 0.31 3.33%

gzip 724 1.55 1.59 2.6%

Table 3: Unix utilities sandboxed during the procedure of

sandboxing RVM’s installer script.

Unix Utilities/Commands

File System Privilege Lookup and Search Others

mkdir

mktemp

date

uname

chmod

chown

Which

cat

ﬁle

grep

ﬁnd

sort

tee

awk

head

stat

sed

xargs

be proxied to the supervisor process. The evalua-

tions show that in the most time-consuming mode, the

sandboxed version of RVM’s installer, as our heaviest

case of study, is 10% slowed down.

The focus of this study was on installer shell

scripts and the corresponding utilities, which are not

in the category of time-sensitive applications like real-

time systems. Therefore, this performance is accept-

able, considering that robust security is achieved as

the supervisor executes the target program in the least

privileged environment. In case of being compro-

mised, the violating call will fail due to capability vi-

olations or failure in accessing the asked information,

which ends up with process termination in the worst

case, and no system corruption or information leakage

would threaten the system.

5.2.1 Comparison with Unix Technologies

In this section, we compare Leash with similar

lightweight application-level systems that are able to

transparently sandbox one application in Unix. Table

4 shows the results obtained from isolating RVM’s in-

staller script using FreeBSD’s Jail (FreeBSD Founda-

tion, 2000), compared to Leash. Jail is a container-

based isolation system for Unix that does not boot a

new OS on the host OS but simulates the ﬁle system

and its environment mainly based on the idea behind

chroot(2). In terms of the complexity of setup and

conﬁguration, Jail needs a container, an instance of

the OS, to be made even for isolating just one applica-

tion. It also requires root privilege for setups. In terms

of the required system resources, jails occupy consid-

erable disk space, as shown in Table 4. This can be a

barrier to using them for trivial cases or when there is

a lack of space. Starting a Jail service and executing

an application inside it is much slower, 3.43 times in

our test cases, than sandboxing by Leash. However,

Jail cannot be applicable for some cases, such as up-

dating or installing changes to the home directory.

We also compared Leash with CapExec (Jadidi

et al., 2019). CapExec was a prototype that demon-

strated limited transparent sandboxing on Unix. How-

ever, as it was tightly dependent on libcasper(8) in

terms of the supported services, it was incapable of

sandboxing many of the utilities and applications that

are sandboxed in this study. CapExec was tested on

small utilities such as cat(8) and traceroute(8)

and demonstrated an average of 28% slowdown.

It showed faster than Leash for smaller programs

(ﬁg. 3), but less capable and incomplete to be con-

sidered as a generic sandboxing system.

5.2.2 Comparison with Linux Technologies

As outlined in section 2.2, the implementation of "ca-

pabilities" in Linux differs signiﬁcantly from true ob-

ject capabilities. Consequently, there is no direct

equivalent to Capsicum or Leash on Linux, though

several sandboxing tools exist.

AppArmor, integrated into Ubuntu in 2007, is a

Linux security model for deﬁning Mandatory Ac-

cess Control (MAC) rules(Gruenbacher and Arnold,

2007). Unlike Leash, AppArmor requires root priv-

ilege and static conﬁguration. For application sand-

boxing, AppArmor is less ﬂexible and more compli-

cated to conﬁgure than Leash.

Decap, designed based on Linux "capabilities", is

a tool for analyzing binaries to remove unnecessary

privileges and enforce required "capabilities" by ex-

amining likely system calls (Hasan et al., 2022). It

helps ensure that applications execute with only the

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

547

Table 4: Comparison on Leash and FreeBSD’s Jail in sandboxing RVM’s installer script.

Execution of RVM’s installer

with isolation

FreeBSD’s Jail

Performance

Details

Usage Details

Execution of RVM’s installer

(Native Program) Leash

Starting jail Installation by jexec Stoping the jail

Memory Usage

Maximum Resident Set Size

Average Shared Memory Size

Average Unshared Data Size

Average Unshared Stack Size

Page Reclaims

Page Faults

Swaps

Block Input Operations

Block Output Operations

Messages Sent

Messages Received

Signals Received

Voluntary Context Switches

Involuntary Context Switches

12196

269

128

276994

2122

15337

7912

16177

90324

106

262932

1806

57209

71388

45514

7044

128

17260

204

2051

799

9924

228

122

325479

1747

7514

6803

9891

6620

128

13236

168

7010

566

Time (second) 5.68 6.25 15.39

Required

Disk Space

(Container)

0 0 4.0 G

necessary privileges, reducing attack surfaces. Like

Leash, Decap is based on mapping system calls to re-

quired Linux "capabilities".

Similar to Decap, LiCA (Sun et al., 2022) is

another Linux "capability" framework that identi-

ﬁes excessive "capability" assignments by analyzing

code ﬂow through LLVM Intermediate Representa-

tion (LLVM IR). Unlike Decap, LiCA does not of-

fer "capability" enforcement, and to employ LiCA’s

result, the source code should change accordingly.

LiCA and Decap do not address the problem of

generic transparent sandboxing, and neither system

deﬁnes the isolation mode, the disallowed behaviours,

and resource access policies.

6 RELATED WORK

In this section, we review the alternative approaches

for secure software installation, along with examples

of sandboxing systems and Unix security features that

facilitate application-level sandboxing.

6.1 Unix Sandboxing Tools

The chroot(2) system call is a key feature for pro-

cess isolation in Unix-like systems, restricting a pro-

cess to a speciﬁed ﬁle system hierarchy. This laid the

foundation for later sandboxing tools like OpenBSD’s

unveil() and FreeBSD’s Jail(8). While unveil()

is similar to chroot(), it improves security by allow-

ing developers to set speciﬁc permissions for the root

directory.

RLBox is a C++ framework integrated with the

Clang compiler, designed to facilitate the creation of

a secure memory boundary for applications. It pro-

vides API support, type checking, and data marshal-

ing to control data ﬂow to and from sandboxed li-

braries (Narayan et al., 2021). One of RLBox’s no-

table features is its API for cross-sandbox commu-

nication, allowing secure interactions between differ-

ent sandboxed contexts. Central to this framework

are "tainted types," which drive a type-safe approach;

however, it requires modiﬁcations to existing code

and emphasizes memory safety.

Other approaches to sandboxing include

OpenBSD’s Pledge and Linux’s Seccomp-BPF,

both of which impose restrictions based on a deﬁned

set of allowed system calls (Hughes, 2015; Linux

Kernel Documentation, 2012). Developers can

specify which system calls a target program can

use, enhancing security by reducing potential attack

surfaces. When a process calls pledge(), it enters

a restricted environment where only the designated

system calls are permissible. In contrast, while

Seccomp-BPF provides a more complex and ﬂexible

mechanism for deﬁning non-blocking system calls, it

also allows for redeﬁnition and replacement of calls,

effectively acting as a static interposition mechanism.

Despite its ﬂexibility, both Pledge and Seccomp-BPF

necessitate modiﬁcations to the application’s code.

FreeBSD’s Capsicum framework takes sandbox-

ing a step further by establishing a robust sand-

box mode that limits global namespaces, ensur-

ing that these restrictions cannot be bypassed once

cap_enter() is called (Watson et al., 2010; Ander-

son, 2017). Utilizing Capsicum requires signiﬁcant

code redesign, but it offers enhanced security by pre-

venting unauthorized access to resources.

Additionally, FreeBSD’s libcasper(8), a li-

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

548

brary derived from Capsicum, provides a suite of

widely-used services designed to operate within Cap-

sicum’s sandbox. These services include Capsicum-

compatible APIs for networking, DNS resolu-

tion, ﬁle handling, and speciﬁc system calls like

getgrent(3), getpwent(3), sysctlbyname(3),

and syslog(3). While libcasper(8) simpliﬁes the

developer experience, it still conﬁnes users to a lim-

ited set of features.

Several sandboxing methodologies focus on track-

ing and interposing system calls. For instance, Li et

al. proposed a model for intrusion detection that re-

lies on system call interception, control, and data ﬂow

assessment (Li et al., 2010). Their system intercepts

each system call, evaluating it against a predeﬁned

policy to ensure it aligns with expected behaviour.

While effective in capturing system call contexts with

manageable overhead, it faces challenges with policy

complexity and performance for larger applications.

Similarly, Ul Haq et al. described an isolation sys-

tem for Linux that integrates Seccomp-BPF, AppAr-

mor, Dune, and ptrace to restrict application access

to system resources (Linux Kernel Documentation,

2012; Gruenbacher and Arnold, 2007; Belay et al.,

2012). Their approach translates deﬁned restrictions

into Dune, leveraging hardware virtualization exten-

sions (Intel VT-x) for a virtual machine-like isolation.

The policy deﬁnition is complex, requiring extensive

kernel interaction and high-level privileges, which in-

creases performance overhead. In contrast, the ap-

proach adopted in Leash eliminates the need for hard-

ware involvement. It simpliﬁes policy deﬁnition using

available resources, eliminating the need for complex

translations or additional instructions. This frame-

work prepares resources for the sandbox without re-

quiring further veriﬁcation.

Unix containers, such as FreeBSD’s Jail(8), of-

fer a form of sandboxing by creating isolated execu-

tion environments that mimic the host OS. While they

provide good isolation, containers incur high mem-

ory and disk overhead, making them inefﬁcient for

sandboxing individual applications, especially when

secure modiﬁcations to the host system are needed.

Additionally, securing host machines against exploits

originating from containers or hyper-visors remains a

challenge as described in recent studies(Bhanumathi

et al., 2023; Win et al., 2017). This ongoing debate

highlights that, while containers offer isolation, they

do not provide the same level of security as sandbox-

ing, particularly in protecting the host from guest ap-

plications and vice versa.

In summary, sandboxing encompasses a range of

defensive strategies designed to impose behavioural

restrictions on programs, thereby mitigating risks and

potential damages to systems from exploits. The pri-

mary objective is to prevent or minimize future harm

and information leakage resulting from vulnerabilities

in applications. Approaches addressing issues such as

malicious code, application restrictions, conﬁnement,

and program compartmentalization all are counted in

this category (Greamo and Ghosh, 2011). Design-

ing a sandboxing mechanism targets speciﬁc vulner-

abilities, deﬁning limitations that prohibit certain be-

haviours through instructions, system calls, and ac-

cess controls (Ansel et al., 2011; Watson et al., 2010).

Variations in resource protection, behaviour deﬁni-

tions, and limitations lead to different sandboxing

mechanisms with distinct purposes and effectiveness.

6.2 Secure Package Management

This study primarily was focused on enhancing the se-

curity of installer applications, which are critical com-

ponents in software deployment. In this section, we

delve into various security mechanisms that have been

implemented in package managers on Linux and Unix

systems. Package managers are crucial for verify-

ing software integrity and auditing known vulnerabili-

ties before installation, thus ensuring system security.

Copper et al. provide an in-depth analysis of these

security mechanisms (Cappos et al., 2008). While

Unix and Linux package managers were not initially

security-focused, they have evolved to address vari-

ous concerns. For example, the Advanced Packag-

ing Tool (APT) in Debian-based distributions uses Se-

cure APT, which authenticates repositories with cryp-

tographic signatures to ensure packages come from

trusted sources. However, this mechanism lacks a

conﬁnement-based model, potentially limiting its ef-

fectiveness in certain scenarios.

FreeBSD’s package manager includes key secu-

rity features, such as auditing archives for known vul-

nerabilities, verifying package checksums, and issu-

ing warnings about installation privileges (FreeBSD

Foundation, 2023). The pkg(8) utility also oper-

ates within a sandbox using Capsicum, adding pro-

tection by isolating package management operations.

However, these security measures are limited by the

repositories supported and the vulnerabilities already

identiﬁed. Poudriere is another package builder for

FreeBSD that enables users to compile packages for

multiple architectures on a single machine (Seaman,

2011). It enhances security by compiling packages

within jails preventing unwanted remote connections.

This approach ensures a clean build process, includ-

ing only the necessary dependencies for the package’s

functionality. Nix, a non-native package manager, ad-

dresses the challenges of managing varying depen-

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

549

dency versions (Kowalewski and Seeber, 2022). Orig-

inally designed for this purpose, it has evolved into a

platform offering isolated, atomic, and reproducible

package builds. Nix uses cryptographic hashes for

each building entity, enabling users to detect any ma-

licious alterations to source code before installation,

thereby improving software management security.

In addition to package managers, several tools

specialize in scanning and auditing software pack-

ages, such as Package Analysis, NPM Audit, Git-

Lab’s Dependency Scanning, and Container Scanning

(GitHub Team, 2020; NPM Documentation, 2018;

GitHub Team, 2018b; GitHub Team, 2018a). These

scanners perform static analysis to validate software

and its dependencies, identifying vulnerabilities and

security risks. However, none of these studies have

examined the dynamic analysis and monitoring of in-

stallation programs, which could offer valuable in-

sights into real-time security during software instal-

lation.

7 FUTURE WORK

From a software engineering perspective, there are

opportunities to enhance Leash into a general-purpose

transparent sandboxing system on FreeBSD that can

support a wide range of applications. This can be

achieved by interposing the whole set of system calls

prohibited under Capsicum’s sandboxing mode. Cur-

rently, Leash supports applications whose disallowed

functions are a subset of the list showed in Table 1,

redirecting such calls to a supervisory module, except

when they can be resolved based on the working di-

rectory.

In addition to supporting more functions, optimiz-

ing the policy speciﬁcation could reduce communi-

cation overhead and improve system call handling,

ultimately leading to better performance. Currently,

Leash operates based on user-deﬁned policies, which

can become a usability bottleneck. While Leash’s

logging mode helps by providing a list of disallowed

calls to restricted resources, user veriﬁcation is still

required. Our goal is to simplify this process and en-

hance user transparency through more readable and

convenient policy speciﬁcation. This area could be a

focus of future improvements, where we could also

explore the integration of AI technologies. In sum-

mary, by extending support for system calls, opti-

mizing policies, and improving user interface clarity,

Leash has the potential to become a robust, ﬂexible,

and user-friendly sandboxing solution for Unix.

8 CONCLUSION

In this paper, we described the design and behaviour

of our prototype towards a general-purpose sandbox-

ing supervisor for Unix. Leash is designed based on

FreeBSD’s capability-based security platform, Cap-

sicum. To our best knowledge, this is the ﬁrst trans-

parent sandboxing supervisor designed for FreeBSD,

which executes the target program in the sandbox

mode without needing code modiﬁcation and high ac-

cess privileges such as root.

Compared to previously Capsicum-derived mod-

ules, such as libcasper(8) and CapExec (Jadidi

et al., 2019), Leash provides new features and im-

provements. The system is a user-interactive frame-

work designed for risk mitigation according to pro-

grams behaviours. Leash categorizes programs’ be-

haviours into four primary domains: ﬁle system re-

quests, network communications, system control re-

quests, and process management.

We have evaluated the behaviour of Leash by

sandboxing the installer script of Ruby Version Man-

ager (RVM), and some utilities including Curl, Fetch,

Gzip and Gtar, as real-world examples. During the

sandboxing of RVM’s installer, there were other Unix

commands needed to be sandboxed inevitably. So,

this investigation ended up with sandboxing 21 of

other Unix commands, all described in section 5.

Leash supports the interposition and functionality

maintenance of the disallowed system calls listed in

Table 1. Our evaluation shows that the sandboxed

RVM’s installer, as our most complicated case study,

is 10% slower than the original version by average.

This overhead contains managing 1009 forked pro-

cesses, which had to run in the sandbox, too. In to-

tal, 17433 system calls were interposed, from which

12191 were proxied and managed by the supervisor

process. This study shows that, despite the inten-

sive restrictions that Capsicum applies, Leash makes

transparent sandboxing achievable and provides prac-

tically efﬁcient service to secure untrusted applica-

tions.

ACKNOWLEDGEMENTS

We gratefully acknowledge the support of the NSERC

Discovery program (RGPIN-2015-06048).

REFERENCES

Anderson, J. (2017). A comparison of unix sandboxing

techniques.

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

550

Anderson, J. P. (1972). The protection of information in

computer systems. In Proceedings of the 1972 ACM

Annual Conference.

Ansel, J., Marchenko, P., Erlingsson, U., Taylor, E., Chen,

B., Schuff, D. L., Sehr, D., Bifﬂe, C. L., and Yee, B.

(2011). Language-independent sandboxing of just-in-

time compilation and self-modifying code. ACM.

Belay, A., Bittau, A., Mashtizadeh, A., Terei, D., Mazières,

D., and Kozyrakis, C. (2012). Dune: Safe user-level

access to privileged CPU features. In 10th USENIX

Symposium on Operating Systems Design and Imple-

mentation (OSDI 12).

Bhanumathi, M, K., S K, S. G., and Deb, P. (2023). Secur-

ing docker containers: Unraveling the challenges and

solutions. In 2023 Fourth International Conference

on Smart Technologies in Computing, Electrical and

Electronics (ICSTCEE).

Cappos, J., Samuel, J., Baker, S., and Hartman, J. H. (2008).

Package management security. University of Arizona.

Dennis, J. B. and van Horn, E. (1975). Capability-based

addressing. In Proceedings of the ACM Annual Con-

ference.

Fabry, R. S. (1974). Capability-based addressing. ACM.

FreeBSD Foundation (2000). An introduction to freebsd

jails. Accessed June 11, 2024.

FreeBSD Foundation (2023). Chapter 4. installing applica-

tions: Packages and ports. Accessed June 11, 2024.

GitHub Team (2018a). Container scanning documentation.

Accessed June 11, 2024.

GitHub Team (2018b). Dependency scanning documenta-

tion. Accessed June 11, 2024.

GitHub Team (2020). Package analysis documentation. Ac-

cessed June 11, 2024.

Greamo, C. and Ghosh, A. (2011). Sandboxing and virtual-

ization: Modern tools for combating malware.

Gruenbacher, A. and Arnold, S. (2007). Apparmor technical

documentation. SUSE Labs/Novell.

Hasan, M. M., Ghavamnia, S., and Polychronakis, M.

(2022). Decap: Deprivileging programs by reducing

their capabilities. In Proceedings of the 25th Interna-

tional Symposium on Research in Attacks, Intrusions

and Defenses, New York, NY, USA. Association for

Computing Machinery.

Hughes, J. (2015). Pledge: Lighter than a jail. In Proceed-

ings of the 2015 USENIX Annual Technical Confer-

ence. USENIX Association.

Jadidi, M. S., Zaborski, M., Kidney, B., and Anderson, J.

(2019). Capexec: Towards transparently-sandboxed

services. In 2019 15th International Conference on

Network and Service Management (CNSM), pages 1–

5. IEEE.

Kowalewski, M. and Seeber, P. (2022). Sustainable packag-

ing of quantum chemistry software with the nix pack-

age manager.

Li, Z., Cai, H., Tian, J., and Chen, W. (2010). Appli-

cation sandbox model based on system call context.

In 2010 International Conference on Communications

and Mobile Computing.

Linux Kernel Documentation (2012). Seccomp bpf (secure

computing with ﬁlters). Accessed June 11, 2024.

Linux man-pages project (2022). libcap. Accessed: 2024-

12-1, Last edit: 2022.

Linux man-pages project (2024). Capabilities. Accessed:

2024-12-1, Last edit: 2024.

Narayan, S., Disselkoen, C., and Stefan, D. (2021). Tuto-

rial: Sandboxing (unsafe) c code with rlbox. In 2021

IEEE Secure Development Conference (SecDev),

pages 11–12. IEEE.

NPM Documentation (2018). Auditing package dependen-

cies for security vulnerabilities. Accessed June 11,

2024.

RVM (2009). Rvm: Ruby version manager - rvm ruby ver-

sion manager. Accessed on May 11, 2024.

Seaman, M. (2011). Poudriere - ports build and test system.

Sun, M., Song, Z., Ren, X., Wu, D., and Zhang, K. (2022).

Lica: A ﬁne-grained and path-sensitive linux capabil-

ity analysis framework. New York, NY, USA. Associ-

ation for Computing Machinery.

UCL Documentation (2014). Ucl - universal conﬁgura-

tion language | github. Open-source project, Accessed

June 11, 2024.

Watson, R. N., Anderson, J., Laurie, B., and Kennaway, K.

(2010). Capsicum: Practical capabilities for UNIX. In

19th USENIX Security Symposium (USENIX Security

10).

Win, T. Y., Tso, F. P., Mair, Q., and Tianﬁeld, H. (2017).

Protect: Container process isolation using system

call interception. In 2017 14th International Sym-

posium on Pervasive Systems, Algorithms and Net-

works & 2017 11th International Conference on Fron-

tier of Computer Science and Technology & 2017

Third International Symposium of Creative Comput-

ing (ISPAN-FCST-ISCC).

Leash: A Transparent Capability-Based Sandboxing Supervisor for Unix

551