Permissions & System Access Audit — ScorpioX Clang Codebase

Audit Date: 2026-04-28 Auditor: Security Audit Agent Scope: OS-level permissions, system access, process spawning, privilege model, and sandboxing Codebase: 148 non-vendor C source files (~125,525 lines) across scorpiox/ directory

---

1. Permissions Summary

---

2. Privilege Requirements

2.1 Tools That Require Root

2.2 Tools That Optionally Run as Root

2.3 Tools That Run Fully Unprivileged

All other ~60+ tools (sx, scorpiox-bash, scorpiox-agent, scorpiox-server, scorpiox-fetch, etc.) run without any elevated privileges. The HTTP server (scorpiox-server) defaults to port 8080 (unprivileged).

2.4 Privileged Helper Dependency

scorpiox-unshare references setuid helpers /usr/bin/newuidmap and /usr/bin/newgidmap for non-root multi-UID mapping. These are standard Linux setuid binaries, not shipped with the codebase. No setuid/setgid/seteuid/setegid calls exist anywhere in the codebase. The code never escalates its own privileges.

---

3. Process Spawning Inventory

3.1 Process Spawning Frequency

42 source files spawn child processes. Top spawners by call count:

3.2 Process Spawning Mechanisms Used

3.3 Critical system() Call Sites

Several system() calls construct commands from runtime data:

• scorpiox-unshare.c:784: snprintf(cmd, ..., "newuidmap %d 0 %d 1 1 %lu %lu", child_pid, ...) — arguments are numeric PIDs/UIDs, low injection risk
• scorpiox-unshare.c:1308: Package installation: system(cmd) where cmd contains package names from CONTAINER_PACKAGES env var — ⚠️ unsanitized environment variable input
• scorpiox-agent.c:382: system(cmd) for git clone/checkout operations — input from user-provided agent URLs
• scorpiox-hook.c:640: Async hook execution via system(full_cmd) — executes user-defined scripts
• scorpiox-wsl.c:876: Complex chroot+overlay command string built with user-provided args

3.4 What Processes Are Spawned

---

4. Filesystem Access Scope

4.1 Primary Data Directories

4.2 System Paths Accessed

4.3 Container Filesystem Scope (scorpiox-unshare)

Inside the container, the process creates a complete isolated rootfs:

• Root filesystem: overlayfs (preferred) or bind-mount of extracted .tar image
• /proc: Fresh procfs mount (within user namespace)
• /sys: Read-only sysfs mount
• /dev: tmpfs with bind-mounted device nodes from host
• /dev/pts: Fresh devpts instance
• /dev/shm: tmpfs
• /tmp, /run: Fresh tmpfs mounts
• /opt/host-bin: Read-only bind-mount of host scorpiox binaries
• User bind-mounts: --bind and -v options for host directory sharing

---

5. System Call Analysis

5.1 Namespace & Container Syscalls

5.2 KVM Virtualization Syscalls

5.3 Memory Mapping

No PROT_EXEC mappings exist anywhere in the codebase. No mprotect() calls. No JIT or self-modifying code. This is a strong security positive.

5.4 Signal Handling

Standard signal handling patterns used across the codebase:

• SIGINT/SIGTERM/SIGHUP: Cleanup handlers in scorpiox-unshare, scorpiox-wsl, scorpiox-traffic, scorpiox-whatsapp, scorpiox-vm, scorpiox-thunderbolt4
• SIGCHLD: SIG_IGN for auto-reaping children (sxmux_session)
• SIGPIPE: SIG_IGN for network robustness (multiple components)
• SIGWINCH: Terminal resize handling (sx_term.c, scorpiox-vi.c)
• SIGILL: CPU feature detection in mbedTLS (vendor code only)

5.5 Other Notable Syscalls

---

6. Sandboxing / Isolation Model

6.1 Container Isolation (scorpiox-unshare)

scorpiox-unshare implements a comprehensive Linux container runtime with multi-layer isolation:

6.2 Isolation Gaps

6.3 VM Isolation (scorpiox-vm)

KVM-based VMs provide hardware-level isolation:

• Full CPU/memory/device separation via KVM
• Separate guest memory region (mmap + KVM_SET_USER_MEMORY_REGION)
• Optional TUN/TAP networking with bridge support
• Shared directories via 9p/virtio or custom initramfs injection

6.4 WSL Isolation (scorpiox-wsl)

Windows-specific: uses WSL's built-in isolation + overlayfs chroot within WSL for additional filesystem isolation.

---

7. IPC Mechanisms

No shared memory (shm_open, shmget) or message queues (mqueue) are used.

---

8. Environment Modification Analysis

8.1 Standard Environment Setting

These are benign, expected modifications within container/child contexts:

8.2 Security-Sensitive Environment Modifications

Mitigating context: These modifications are intentional — scorpiox-traffic is explicitly a traffic capture/MITM tool. The environment changes are applied only to the child process being monitored (fork() + execvp() at line 984), not globally. However, the tool's purpose inherently requires weakening TLS security for the wrapped process.

8.3 No LD_PRELOAD / LD_LIBRARY_PATH Modification

The codebase does not modify LD_PRELOAD or LD_LIBRARY_PATH anywhere. No dynamic library injection vectors exist.

---

9. Principle of Least Privilege Assessment

9.1 Strengths

9.2 Weaknesses

---

10. Risk Assessment

10.1 Risk Matrix

10.2 Overall Assessment

The ScorpioX codebase demonstrates a generally sound security architecture for a systems-level toolkit:

• Container isolation (scorpiox-unshare) follows industry-standard patterns (matching Docker/Podman rootless) with user namespaces, mount isolation, PID isolation, network isolation, and filesystem isolation via pivot_root.
• No privilege escalation is attempted anywhere — the code never calls setuid/setgid/prctl for privilege gain.
• Memory safety is enhanced by the absence of executable memory mappings (no JIT, no W^X violations).
• The main risks center on the extensive use of system() for shell command execution (command injection surface) and the absence of seccomp filtering in containers.

Overall Risk Rating: MEDIUM — The codebase is well-structured with clear separation of privileged operations, but would benefit from replacing system() calls with direct exec, adding seccomp filters to containers, and using secure temporary file creation patterns.

---

Report generated by Security Audit Agent on 2026-04-28