# Snigdha OS Decentralized - Confinement & Isolation Security Threat Model

Subsystem: Snigdha Isolation (Phase 5)
Author: Snigdha OS Security Architecture Team
Classification: Public Security Specification
Status: ENFORCED

# 1. Scope & Objective

The primary mission of Snigdha Isolation is to prevent or minimize the blast radius of compromised or adversarial applications within the live Snigdha OS environment. By enforcing strict Mandatory Access Control (AppArmor), unprivileged multi-namespace sandboxing (Bubblewrap), D-Bus filtering (xdg-dbus-proxy), kernel system call filters (Seccomp-BPF), and systemd service hardening, the subsystem strictly limits what an adversary can access if any single application binary or service is exploited.

# 2. Protected Assets

The isolation architecture is designed to defend the following assets:

# 3. Threats Mitigated

Snigdha Isolation actively mitigates and confines the following threat vectors:

# 3.1 Compromised Desktop Applications

If an interactive application (terminal emulator, file manager, image viewer, or document tool) is exploited via memory corruption or malicious file input:

• The process cannot read or tamper with system binaries (protected by read-only /usr mounts).
• The process cannot see or tamper with peer processes on the desktop (protected by PID and IPC namespaces).
• The process cannot write to persistent disk storage or modify system boot configurations.

# 3.2 Malicious Documents & Downloaded Files

Untrusted media (images, PDFs, documents) executed via sandboxed viewers (feh, image tools):

• Run in strictly offline network mode with isolated network namespaces (--unshare-net), eliminating telephone-home or exfiltration channels.
• Have zero access to internet sockets or external IP routes.
• Cannot inspect or read unrelated user directories.

# 3.3 Unauthorized Persistent Storage Snooping

When persistent storage is locked:

• The persistent directory ~/Persistent is masked with an empty tmpfs mount inside every sandbox.
• Raw block device nodes (/dev/sd*, /dev/nvme*) and device-mapper containers (/dev/mapper/*) are denied by AppArmor and excluded from the sandbox /dev tree.
• When unlocked, only explicitly authorized feature paths are selectively bound into permitted sandboxes.

# 3.4 Direct Network Bypasses Around NetGuard

An adversary attempting to bypass Tor network interception:

• Cannot escape nftables redirect rules in host-enforced mode.
• Cannot establish raw sockets or use direct network namespaces to route packets around NetGuard.
• Cannot inspect or modify firewall rules (CAP_NET_ADMIN dropped, nftables denied).

# 3.5 Privilege Escalation via Capabilities & SUID

• All user-facing sandboxed processes execute with zero Linux capabilities (deny capability in AppArmor).
• User namespace UID mapping maps the sandboxed user to unprivileged IDs.
• NoNewPrivileges=yes is enforced across all sandboxes and background services, preventing setuid escalation.

# 3.6 D-Bus Service Manipulation

• Sandboxed processes communicate with D-Bus exclusively through xdg-dbus-proxy.
• Calls to administrative interfaces (org.snigdha.NetGuard1, org.snigdha.Persistence1, org.freedesktop.systemd1) are blocked at proxy level, returning AccessDenied.

# 4. Threats Not Guaranteed to be Defeated (Architectural Boundaries)

To maintain absolute engineering integrity, the following limitations are explicitly recognized:

1. Compromised Linux Kernel: If an attacker executes a zero-day exploit targeting the running kernel (e.g., local privilege escalation via unpatched kernel bug), software sandboxes running on that kernel cannot guarantee containment.
2. Malicious Firmware & Hardware Attacks: Compromised UEFI firmware, BIOS implants, or DMA attacks over PCIe/Thunderbolt ports operate beneath the operating system.
3. Shared X11 Display Protocol (Boundary 2): Under the Xorg/i3wm architecture, all GUI applications sharing the host $DISPLAY connect to the same X11 socket. An exploited graphical client can observe window contents, log keystrokes, or inject synthetic events to peer GUI clients running on the same X display. (See docs/X11-SECURITY-LIMITATIONS.md).
4. Physical Memory Extraction: An adversary with liquid nitrogen or physical access to memory chips prior to system poweroff (mitigated partially by Amnesia memory erasure on controlled shutdown, but physical attacks remain out of software scope).
5. Supply Chain Compromise: If trusted upstream Arch Linux packages or base libraries are backdoored before distribution, software isolation can only restrict their runtime permissions, not eradicate malicious intent.