Skip to content

View Only Sandbox & Permission Escalation

underd0se edited this page Sep 5, 2026 · 3 revisions

🛡️ View-Only Sandbox & Permission Escalation

The Restricted View-Only Shell in TAILCAT ZER0 is implemented by a dedicated hardened wrapper script: tailcat-view-shell.

It delivers a zero-trust diagnostic environment for external technicians, script developers, and forum helpers. It allows read-only visibility into system health, routing, NVRAM, and logs while strictly preventing state modification, data theft, and hardware corruption.


🏗️ Sandbox Architecture

When a guest connects to a view-only session, TailCat attaches their PTY to tailcat-view-shell instead of /bin/sh. Every command entered by the guest is intercepted, tokenized, and evaluated against multi-layer security rules before anything reaches the kernel.

               +----------------------------------------+
               |        GUEST TERMINAL (TailCat)        |
               +----------------------------------------+
                                   |
                                   v
               +----------------------------------------+
               |           tailcat-view-shell           |
               +----------------------------------------+
                                   |
           +-----------------------+-----------------------+
           |                       |                       |
           v                       v                       v
    [Syntax Check]       [Path & Credential]        [GTFOBin Check]
 - No redirects (>, <)   - Block /etc/shadow        - No 'sort -o'
 - No subshells ($())    - Block .ssh/id_*          - No 'env <cmd>'
 - No chaining (; &&)    - Block dropbear keys      - No interactive
 - Pipe check (A | B)    - Filter 'nvram show'        pager breakouts
           |                       |                       |
           +-----------------------+-----------------------+
                                   |
                     Is command in Allowlist?
                                   |
                    +--------------+--------------+
                    |                             |
                 [ YES ]                       [ NO ]
                    |                             |
                    v                             v
           +------------------+         +-------------------+
           | Execute Pipeline |         | Blocked: Offer    |
           +------------------+         | 'request <cmd>'   |
                                        +-------------------+

📋 Default Allowed Commands

The sandbox provides access to all standard diagnostic tools:

Category Allowed Commands
System Health uptime, free, df, ps, top (batch mode), dmesg, sysinfo, uname, cat /proc/*
Network & WiFi ip addr, ip route, ip neigh, ifconfig, netstat, route, ports, ping, mtr, wl, leases, wifi
NVRAM & Configs nvram get <var>, nvram show (sanitized)
System Logs logread, cat /tmp/syslog.log
Entware Package Queries opkg list, opkg info, opkg status, opkg find, opkg search, opkg depends
Text Processing & Inspection cat, head, tail, grep, egrep, fgrep, rg, sed, awk, cut, wc, diff, tree, sort, uniq
Pipelines Full Unix pipelines (|) permitted between allowed inspection tools (e.g. ps | grep dnsmasq)

🚫 Blocked Syntax & Threat Mitigations

To prevent shell escapes and system tampering, the following syntax patterns are strictly rejected:

1. Output Redirection (>, >>, <)

  • Guests cannot redirect command output to files or overwrite arbitrary locations.
  • Example blocked: echo "malicious" > /jffs/scripts/post-mount

2. Command Chaining (;, &&, ||)

  • Commands must be single operations or standard Unix pipes (|). Chaining commands to sneak unallowed binaries past filters is blocked.
  • Example blocked: uptime; rm -rf /jffs

3. Subshells & Command Substitution ($(), `)

  • Nesting command execution inside arguments or variables is forbidden.
  • Example blocked: cat $(which nvram)

4. Sensitive File & Credential Protection

Access to router credential repositories is denied, even using cat, head, or grep:

  • /etc/shadow, /tmp/etc/shadow, /tmp/shadow
  • /jffs/ssl/, /etc/dropbear/, /jffs/.ssh/id_*
  • nvram show and nvram get automatically filter and redact password and key variables (such as http_passwd, wpa_psk, acc_webdav_password).

5. GTFOBin Defenses

Many standard Unix utilities include secondary flags capable of writing files or invoking subshells. TAILCAT ZER0 explicitly hardens against these:

  • sort -o <file>: Blocked because -o writes output directly to a file.
  • uniq [input] [output]: Two-argument invocation blocked to prevent file overwrites.
  • xxd -r: Reverse hex dump writing blocked.
  • env <command>: Blocked from launching arbitrary child executables.
  • less / more: Interactive pager shell breakout (!) is stripped or redirected to non-interactive streaming mode.

🛑 Hard Red Lines (Irreversible Hardware Safeguards)

Certain destructive commands can cause permanent flash memory corruption or brick router hardware. These commands are designated as Hard Red Lines and are hard-blocked from ever being requested, approved, or executed under any circumstances:

  • dd of=/dev/mtd* or writing to any /dev/mtdblock*
  • flash_erase* or nandwrite
  • rm -rf / or rm -rf /jffs
  • nvram erase or nvram restore

Even if the host admin attempts to run tailcatzero allow "rm -rf /", the core sandbox engine will reject it with an irreversible hardware safeguard alert.


🔔 Live On-Demand Permission Escalation

If a remote assistant needs to run a diagnostic tool that is not in the default allowlist (e.g., amtm, curl -I https://dns.google, traceroute 1.1.1.1):

1. Guest Request Flow

When the guest attempts an unapproved command:

Guest Terminal:
$ traceroute 1.1.1.1
[-] Command 'traceroute' is restricted in view-only mode.
Would you like to request permission from the host router admin? [y/N]: y
[*] Permission request submitted (ID: #1). Waiting for host approval...

Or directly using the request command:

$ request traceroute 1.1.1.1

2. Host Alerting

The moment a request is submitted:

  • A broadcast alert is immediately printed across all active host SSH terminals (/dev/pts/*).
  • An event is logged to syslog.
  • The TUI dashboard immediately updates with a prominent badge: [P] 🔔 1 Pending Request.

3. Host Approval Channels

Method A: Via Interactive TUI Modal

Press P on the main menu or active session card to open the Pending Requests Modal:

========================================================================
  🔔 PENDING PERMISSION REQUEST (#1)
========================================================================

  Guest:         Remote Support Guest (View-Only Session)
  Command:       traceroute 1.1.1.1
  Requested At:  20:45:12
  Threat Level:  LOW (Diagnostic utility)

------------------------------------------------------------------------
  ACTIONS:
------------------------------------------------------------------------
  [1] Approve for this session (Cached allowlist in memory)
  [2] Approve once (Single execution only)
  [3] Deny request
  [4] Skip / Review later

  Select action [1-4]: 

GTFOBin Threat Warnings:

If a guest requests a binary that contains known subshell or file-writing vectors (e.g. find -exec, awk 'BEGIN {system()}'), the modal highlights a bold security warning:

⚠️ WARNING: Binary 'find' has known GTFOBin vectors (arbitrary execution).
Review arguments carefully before approving!

Method B: Via Headless CLI

Administrators managing the router via scripts or headless terminal sessions can inspect and resolve requests directly:

# View all pending guest requests
tailcatzero requests

# Approve for the entire duration of the session
tailcatzero approve 1
# or by command name:
tailcatzero approve traceroute

# Approve for a single execution only
tailcatzero approve 1 --once

# Deny a request
tailcatzero deny 1

# Proactively permit or revoke a command
tailcatzero allow iperf3
tailcatzero revoke iperf3

4. Instant Execution

The moment the host approves the request:

Guest Terminal:
[✓] Host approved 'traceroute 1.1.1.1'.
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.812 ms  0.720 ms  0.680 ms
...

Clone this wiki locally