05 — Permissions, Process Spawning, Privilege Model & Sandboxing Audit

Audit Date: 2026-04-28 Codebase: scorpiox/clang Auditor: Security Audit Agent Scope: OS-level permissions, system access, process spawning, privilege model, and sandboxing

---

Executive Summary

The scorpiox codebase is a large, multi-binary C platform encompassing an AI agent shell (sx), a rootless container runtime (scorpiox-unshare), a KVM virtual machine runner (scorpiox-vm), a web server (scorpiox-server), a DNS server (scorpiox-dns), an email stack (IMAP/SMTP), a terminal multiplexer (sxmux), and numerous tool binaries. The project makes extensive use of process spawning (656+ call sites), interacts deeply with Linux namespaces and cgroups, and in most cases operates without elevated privileges. However, several components require or benefit from root access, and certain design choices warrant security attention.

Overall Risk Level: MEDIUM — The container runtime has strong namespace isolation by default, but the broad use of system()/popen() for shell command execution, a hardcoded SSH password, and the number of binaries that can spawn arbitrary processes create a meaningful attack surface.

---

1. Permissions Summary

---

2. Privilege Requirements

2.1 Components That Require Root

scorpiox-thunderbolt4 — The only binary with an explicit root check:

   // scorpiox-thunderbolt4.c:1406
   if (geteuid() != 0) { fprintf(stderr, "error: need root (sudo)\n"); return 1; }
   

Required for BPF access on macOS to do raw Ethernet frame I/O over Thunderbolt.

scorpiox-vm — Needs /dev/kvm (read-write) and /dev/net/tun for TAP networking. Typically requires kvm group membership rather than root.

scorpiox-dns — Binds to UDP/TCP port 53 by default. Port < 1024 requires root or CAP_NET_BIND_SERVICE.

2.2 Components That Benefit From Root

scorpiox-unshare — Designed as rootless, but detects root at runtime:

   // scorpiox-unshare.c:1821
   int skip_userns = (getuid() == 0);
   

When running as root, it skips user namespace creation (matches Docker/Podman behavior) to enable NFS/CIFS bind-mounts inside containers.

scorpiox-wsl.c — Uses chroot within WSL overlayfs containers, which requires root inside the WSL distribution.

2.3 No Privilege Escalation Detected

• No setuid/setgid/seteuid calls anywhere in the first-party codebase.
• No prctl/seccomp/pledge/unveil calls — the codebase does not explicitly drop privileges or apply syscall filters.
• The only reference to setuid helpers is for newuidmap/newgidmap (standard Linux user namespace plumbing):

  // scorpiox-unshare.c:774
  / Non-root: must use newuidmap/newgidmap (setuid helpers) /
  

---

3. Process Spawning Inventory

Total process spawning call sites (non-vendor): 656

3.1 Spawning Mechanisms

3.2 Top Process Spawning Files

3.3 Security-Sensitive Spawning Patterns

Concern 1: system() with constructed strings

// scorpiox-agent.c:382 — arbitrary git commands
int ret = system(cmd);

// sx.c:659 — editor invocation
int ret = system(editor_cmd);

// sxmail_maildir.c:704 — maildir operations
if (system(cmd) != 0) {

Concern 2: popen() with constructed commands

// sxtmux_backend_tmux.c:42
FILE *fp = popen("tmux list-sessions ...", "r");

// scorpiox-agent.c:407
FILE *fp = popen(cmd, "r");

Concern 3: Hook script execution

// scorpiox-hook.c:579 — executes user-supplied hook scripts
FILE *pipe = popen(full_cmd, "r");
// scorpiox-hook.c:640
system(full_cmd);

Hook scripts in .scorpiox/hooks// are executed with full user privileges. No sandboxing or validation of hook content.

3.4 Process Monitoring

The codebase includes a dedicated process monitoring subsystem (sx_procmon.c) using atomic counters to track:

• Fork/reap counts and peak active children
• popen/pclose lifecycle
• pipe open/close counts
• system() call counts

This is a positive security practice for leak detection and audit.

---

4. Filesystem Access Scope

4.1 Primary Access Paths

4.2 Filesystem Access Assessment

• No global filesystem scanning — access is scoped to known paths.
• The container runtime (scorpiox-unshare) properly isolates container filesystem via pivot_root().
• User-specified bind mounts (-v host:container[:ro]) support read-only mode.
• /tmp is used for IPC sockets (sxmux, slirp4netns API) — standard POSIX practice but vulnerable to symlink races without O_NOFOLLOW.

---

5. System Call Analysis

5.1 Kernel Interactions

5.2 Notable Findings

• No PROT_EXEC mmap usage — no JIT or self-modifying code patterns detected.
• No mprotect() calls — no runtime memory permission changes.
• No ptrace() calls — no debugging/inspection of other processes.
• No seccomp() or prctl(PR_SET_SECCOMP) calls — containers do NOT have syscall filtering.

- ⚠️ Gap: The container runtime does not apply seccomp profiles, unlike Docker/Podman which filter ~40+ dangerous syscalls by default.

• KVM ioctl usage (scorpiox-vm.c) is extensive and appropriate for a VM monitor:

- KVM_CREATE_VM, KVM_CREATE_VCPU, KVM_SET_USER_MEMORY_REGION, KVM_RUN

- KVM_SET_SREGS, KVM_SET_REGS, KVM_SET_CPUID2

- KVM_CREATE_IRQCHIP, KVM_CREATE_PIT2, KVM_IRQ_LINE

---

6. Sandboxing / Isolation Model

6.1 Container Runtime (scorpiox-unshare)

The container runtime implements a rootless Linux container model similar to Podman:

Namespace Isolation: Filesystem Isolation:

• Uses pivot_root() to switch to container rootfs — proper isolation.
• Overlayfs when available (kernel ≥ 5.11), falls back to bind-mount.
• /dev is mounted as tmpfs with only essential devices bind-mounted from host.
• /proc mounted with MS_NOSUID | MS_NODEV | MS_NOEXEC.
• /sys mounted read-only.
• /tmp and /run are independent tmpfs mounts.
• Supports read-only volume mounts via MS_BIND | MS_REMOUNT | MS_RDONLY.

Network Isolation:

• Default: CLONE_NEWNET + slirp4netns for userspace networking.
• DNS: Container resolv.conf points to slirp4netns gateway (10.0.2.3).
• Port forwarding via slirp4netns API socket (add_hostfwd).
• Opt-out: --net host shares host network namespace.

Resource Limits:

• Memory limits via cgroup v2: --memory flag writes to /sys/fs/cgroup/sx-/memory.max.
• No CPU limit support detected.

GPU Passthrough:

• NVIDIA + DRI device nodes are bind-mounted into container when --gpu is specified.
• This breaks device isolation but is expected for GPU workloads.

6.2 Container Security Gaps

6.3 KVM Virtual Machine (scorpiox-vm)

• Full hardware-level isolation via KVM.
• Guest memory is mmap()-ed with PROT_READ | PROT_WRITE (no PROT_EXEC on host side).
• TAP networking via /dev/net/tun provides network isolation.
• Uses same .tar rootfs images as the container runtime.
• This is the strongest isolation model in the codebase.

6.4 WSL Container (scorpiox-wsl.c)

• Uses overlayfs + chroot (not user namespaces) for WSL environments.
• Constructs large shell command strings passed to system() or popen().
• ⚠️ Less isolated than scorpiox-unshare — chroot alone is not a security boundary.

---

7. IPC Mechanisms

7.1 Pipe Usage (797+ call sites)

7.2 Notable IPC Patterns

• No shared memory (shm_open, shmget, sem_open) — all IPC is stream/message-based.
• sxmux uses AF_UNIX + SOCK_STREAM with socket dir at ~/.scorpiox/sxmux/ (permissions 0700).
• slirp4netns API socket at /tmp/sx_slirp_.sock — deleted after use.
• scorpiox-server uses fork-per-request model with SIGCHLD reaping for CGI scripts.

---

8. Environment Variable Handling

8.1 Security-Sensitive Environment Variables

8.2 Positive Findings

• No LD_PRELOAD or LD_LIBRARY_PATH manipulation anywhere in the codebase.
• No DYLD_* variable manipulation (macOS).
• Container runtime sets a clean PATH inside containers:

  setenv("PATH", "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", 1);
  

• Environment pass-through into containers is explicit (user-specified -e flags or specific variables like TERM, SCORPIOX_BRANCH).

---

9. Principle of Least Privilege Assessment

9.1 Positive Practices

9.2 Violations / Gaps

---

10. Risk Assessment

10.1 Critical Risks

10.2 High Risks

10.3 Medium Risks

10.4 Recommendations Summary

Eliminate system() calls where possible — the codebase already has sx_exec() with fork()+exec() and timeout support. Route all command execution through it.

Add seccomp-bpf to the container runtime — even a basic profile blocking kexec_load, reboot, mount (after setup), ptrace would significantly improve security.

Remove the hardcoded password from scorpiox-sshpass or gate it behind a build flag.

Add CLONE_NEWIPC | CLONE_NEWCGROUP to the default clone flags in scorpiox-unshare.

Drop privileges in long-running servers (scorpiox-server, scorpiox-dns) after binding ports.

Sandbox hook execution — run hooks in a child with reduced capabilities or inside a container.

---

Appendix A: File-by-File Process Spawning Count

Appendix B: Namespace Isolation Matrix

                    scorpiox-unshare    scorpiox-vm     scorpiox-wsl
Mount NS            ✅ CLONE_NEWNS      N/A (KVM)       ❌ chroot only
PID NS              ✅ CLONE_NEWPID     N/A (KVM)       ❌ No
User NS             ✅ CLONE_NEWUSER*   N/A (KVM)       ❌ No
Network NS          ✅ CLONE_NEWNET†    ✅ TAP/bridge   ❌ Host network
UTS NS              ✅ CLONE_NEWUTS     N/A (KVM)       ❌ No
IPC NS              ❌ Missing          N/A (KVM)       ❌ No
Cgroup NS           ❌ Missing          N/A (KVM)       ❌ No
Seccomp             ❌ None             N/A (KVM)       ❌ None
Capability drop     ❌ None             N/A (KVM)       ❌ None

* Skipped when running as root
† Opt-out via --net host

Appendix C: Methodology

Recursive grep of all non-vendor .c and .h files for process spawning functions (fork, exec*, system, popen, posix_spawn, clone, vfork, CreateProcess, ShellExecute)

Recursive grep for privilege-related syscalls (setuid, setgid, chroot, capset, prctl, seccomp, pledge, unveil)

Recursive grep for kernel interactions (ioctl, ptrace, mmap, mprotect, signal handling)

Recursive grep for namespace/container calls (unshare, setns, clone, CLONE_NEW*, pivot_root, cgroup)

Recursive grep for environment variable manipulation (setenv, putenv, getenv of security-sensitive variables)

Recursive grep for IPC mechanisms (pipes, sockets, shared memory, signals)

Recursive grep for filesystem access (fopen, open, mkdir, unlink, etc.)

Manual code review of critical files: scorpiox-unshare.c, scorpiox-vm.c, sx_exec.c, scorpiox-bash.c, scorpiox-server.c, scorpiox-sshpass.c