To implement Capsicum sandboxing within GhostBSD, it is helpful to proceed in a series of methodical steps. The process begins with identifying existing system utilities, background services, and graphical applications that would benefit from restricted access to system resources. These candidates include tools that read or write files, perform network operations, or interact with user input in a way that could be exploited if not properly constrained. The goal is to identify points in a program's execution after which no further access to new resources is required, making it safe to enter capability mode.
A common use case in GhostBSD involves shell scripts that perform system administration tasks or routine file operations. Although shell scripts cannot directly invoke Capsicum system calls, they can delegate sensitive work to compiled helper programs that are designed to operate within a sandboxed environment. This approach allows for secure isolation while retaining the flexibility of shell scripting.
Consider a script that processes log files and writes summaries to a destination directory. Instead of allowing the script to write directly, it can call a compiled helper that opens the destination file, restricts the file descriptor to write-only access using cap_rights_limit, and then enters capability mode with cap_enter. Once in capability mode, the helper reads input from standard input and writes the summary to the pre-opened destination file. The script itself has no access to the filesystem beyond what is allowed to the helper program. This reduces the attack surface by preventing the helper from opening other files or modifying unintended locations.
Below is an example of such a shell script paired with a simple helper program. The script accepts a file path and some content, and passes that content to the helper which performs the write in a restricted context.
#!/bin/sh
# write-summary.sh
OUTFILE="$1"
CONTENT="$2"
# Check arguments
if [ -z "$OUTFILE" ] || [ -z "$CONTENT" ]; then
echo "Usage: $0 <outfile> <content>"
exit 1
fi
# Open the destination and hand off to the Capsicum-aware helper
echo "$CONTENT" | ./capsicum-writer "$OUTFILE"
The helper program capsicum-writer is written in C. It opens the file, applies Capsicum rights, and then safely writes data.
// capsicum-writer.c
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/capsicum.h>
#include <string.h>
int main(int argc, char *argv[]) {
if (argc != 2) {
fprintf(stderr, "Usage: %s <outfile>\n", argv[0]);
return 1;
}
int fd = open(argv[1], O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd < 0) {
perror("open");
return 1;
}
cap_rights_t rights;
cap_rights_init(&rights, CAP_WRITE);
if (cap_rights_limit(fd, &rights) < 0) {
perror("cap_rights_limit");
close(fd);
return 1;
}
if (cap_enter() < 0) {
perror("cap_enter");
close(fd);
return 1;
}
char buffer[1024];
ssize_t bytes;
while ((bytes = read(STDIN_FILENO, buffer, sizeof(buffer))) > 0) {
write(fd, buffer, bytes);
}
close(fd);
return 0;
}
This simple model demonstrates how shell scripts can incorporate Capsicum indirectly by calling helpers that operate under strict constraints. The script itself remains responsible for user interaction and control flow, but never handles sensitive file writes directly. This separation of duties mirrors the principle of least privilege and offers a practical path to improve system safety without rewriting entire workflows.
More broadly, GhostBSD can encourage this model across the desktop by providing such helpers as system utilities, or by offering wrapper tools that execute applications within a controlled context. System installers, media managers, or update tools could adopt this pattern to ensure safer execution environments.
