Project 11: Termux Security Auditor and Hardening Lab

Build an explainable local auditor that proves concrete authority paths across Termux storage, Android bridges, SSH, listeners, logs, and package trust—without leaking the secrets it finds.

Quick Reference

Attribute Value
Difficulty Level 3 - Advanced
Time estimate 18-28 hours
Main language Python
Alternatives Rust, Go
Prerequisite projects P01-P10, especially storage, Tasker, SSH, services, native/package trust
Primary concepts Threat modeling, least privilege, evidence quality, safe secret handling, rule design, exceptions, regression fixtures
Main tools Private filesystem inspection, SSH configuration parser, listener inventory, package/repository metadata, Android capability observations
Observable outcome A deliberately vulnerable fixture reaches zero unsuppressed high-severity findings through real remediation, with no seeded secret appearing in reports or logs

1. Learning Objectives

By completing this project, you will be able to:

  1. Draw assets, actors, entry points, trust boundaries, data flows, and abuse cases for a Termux-hosted system.
  2. Distinguish an observable fact, an insecure configuration, a vulnerability, and a contextual risk.
  3. Write rules whose findings identify a concrete actor, capability, effect, evidence, remediation, and verification.
  4. Inspect sensitive locations and files without printing or retaining secret contents.
  5. Audit shared-storage exposure, executable writability, SSH authorization, Tasker/RUN_COMMAND authority, listeners, logs, repository trust, and Android permission drift.
  6. Model severity from exploitability and impact rather than from alarming filenames.
  7. Build vulnerable, safe, and ambiguous fixtures before implementing each detector.
  8. Manage false positives through scoped, owned, justified, expiring exceptions and compensating controls.
  9. Prove hardening by changing real configuration, not by suppressing the detector.
  10. Treat the auditor itself as a privileged tool with narrow reads, bounded work, safe logs, and signed policy provenance.

2. Theoretical Foundation

2.1 Core Concepts

Security begins with a system model. A generic checklist cannot tell whether a setting is exploitable in a particular Termux deployment. Start with assets such as keys, queued actions, telemetry, package trust, and remote-control authority. Identify actors: the phone owner, a remote operator, another Android app, a LAN peer, a compromised repository host, and an attacker with access to shared storage. Draw where data or authority crosses between them.

                         ANDROID / EXTERNAL ACTORS
  +----------------------------------------------------------------+
  | other apps | Tasker | classic add-ons | LAN peers | repo host  |
  +--------+---------+----------+---------------+-----------+-------+
           |         |          |               |           |
           v         v          v               v           v
  +----------------------------------------------------------------+
  |                      TERMUX APP SANDBOX                         |
  |                                                                |
  | shared inbox -> validators -> private state -> worker -> actions|
  |                         ^             |           |             |
  |                         |             v           v             |
  |                    package trust    logs       SSH/listeners    |
  +----------------------------------------------------------------+

  Audit question at every arrow:
  who controls the input, what authority crosses, what proves validation,
  what durable effect follows, and what evidence remains?

A trust boundary is a change in control or authority. Shared storage is controlled differently from private HOME. A Tasker event comes from another app with RUN_COMMAND authority. An SSH key authenticates a remote client but must still be authorized to a narrow action. A signed repository authorizes a publisher identity but does not make every package behavior safe. Rules should be organized around these crossings, not around arbitrary directory names.

A finding needs a causal statement. “File mode 0777” is an observation. A good finding states that an actor able to modify that executable can cause a privileged or automated entry surface to run attacker-controlled code in the Termux UID context. Evidence then proves the path, relevant mode/ownership, and invocation relationship without copying sensitive content.

Evidence should be sufficient and minimal. For a suspected key in shared storage, report path class, basename policy or redacted identifier, size range, mode semantics, file type, and a one-way digest or keyed fingerprint. Do not print the key. For a token in a log, record rule ID, log identity, line range or event ID, match class, and digest of the match—never the match itself. The same redaction requirement applies to stdout, JSON, debug logs, exceptions, test snapshots, and telemetry.

Termux security is layered. Android’s app sandbox isolates private data by application UID, but Termux can deliberately expose authority through add-ons, storage, Tasker, SSH, network listeners, and packages. On the classic track, the main app and add-ons must come from the same compatible signing source. The Play track is a separate integration surface. The auditor must record track/capability facts and avoid rules that assume every add-on or directory exists.

Least privilege narrows useful capability. It does not require deleting every integration. A health SSH key can use a forced command and disable forwarding. Tasker can invoke reviewed fixed entry points and pass bounded typed arguments. A local dashboard can bind to loopback. A repository can use a dedicated verified key instead of trusted=yes. Each remediation should preserve the legitimate operation while reducing actor, action, data, time, or network scope.

Secret detection is not secret collection. Content scanning may be justified for known private directories or an explicit lab fixture, but it has a strict byte/time scope and immediate redaction. Prefer metadata and configuration semantics when they prove the issue. Never recursively scan all Android-visible storage by default, never follow untrusted symlinks, never upload findings automatically, and never change files during scan.

Severity is contextual. Combine impact, required access, reachability, authorization, exploit complexity, persistence, and existing controls. A loopback listener is not equivalent to 0.0.0.0; a public listener may be intentional behind a mesh allowlist; a permissive mode on emulated shared storage does not have ordinary Unix meaning. Ambiguous cases should request context or report informational evidence rather than fabricate certainty.

Rules are versioned policy. Each rule has a stable ID, scope, required evidence, applicability conditions, severity rationale, remediation, verification, fixture corpus, and policy version. Changing severity or applicability is a policy release, not an invisible code refactor. The report records the policy digest so later audits can be compared honestly.

Exceptions are risk records, not silence switches. A valid exception identifies rule, exact resource scope, owner, reason, expiry, compensating control, and review date. Expired or unmatched exceptions do not suppress. Exception debt is summarized. Some findings may be non-suppressible under the learner’s policy, but that decision must be explicit and testable.

The scanner itself has authority. Reading private SSH configuration, repository sources, service definitions, and logs can expose sensitive information. Run as the ordinary Termux UID, request no unnecessary Android permission, avoid network egress, use deadlines and file caps, and make the default scan read-only. Remediation should be a separate planned operation requiring confirmation, backup, and verification.

2.2 Why This Matters

Projects accumulate capability. A storage importer, Tasker bridge, SSH service, runit worker, native executable, and private repository may each be reasonable alone; their composition creates new paths. A writable Tasker entry point plus broad RUN_COMMAND authority is more serious than either fact by itself. A package signing key in shared storage defeats the release channel even if APT verification is configured perfectly.

An explainable auditor turns those implicit paths into regression-testable claims. It also teaches a professional security habit: findings must be evidence-backed, safe to share, scoped to the deployed environment, and paired with a verification procedure. “Run a scanner and trust the score” is not the outcome.

2.3 Historical Context / Background

Security assessment evolved from perimeter checklists toward threat modeling, secure configuration baselines, static/dynamic analysis, and continuous posture evidence. Mobile platforms added strong application sandboxing and permission systems, but extensibility and interoperability still create authority crossings. Unix permissions, SSH policy, network binds, logs, and software repositories remain relevant inside Termux’s app sandbox.

Android has continued to tighten storage, background, permission, and network behavior. Meanwhile Termux supports multiple distribution tracks with different integration surfaces. A useful auditor must therefore rely on current runtime evidence and official documentation rather than treating one tutorial’s directory layout or permission set as universal.

2.4 Common Misconceptions

  • “Android sandboxing makes Termux automatically secure.” Deliberate bridges and network exposure still grant authority.
  • “Any permissive mode is critical.” Filesystem semantics, actor access, and invocation determine risk.
  • “A listener on a high port is safe.” Port number does not authenticate clients or narrow interfaces.
  • “SSH keys solve authorization.” A valid key may still grant an unnecessarily broad shell or forwarding.
  • “Signing means a repository package is trustworthy.” It authenticates the publisher, not code quality.
  • “Finding a secret means printing it as proof.” That creates a second exposure.
  • “Zero findings means secure.” Coverage, policy version, unobservable states, and exceptions matter.
  • “Suppressions are remediation.” The risky state remains unchanged.
  • “The scanner may auto-fix everything.” Blind mutation can break access, state, or evidence and exceeds a read-only audit.

3. Project Specification

3.1 What You Will Build

Build pocket-audit, a read-only-by-default auditor with:

  • a versioned threat model and policy bundle;
  • rule groups for storage/secrets, executable integrity, Android bridges/Tasker, SSH, network exposure, logs/privacy, package/repository trust, services, and permission drift;
  • stable human and JSON/SARIF-like results with safe evidence;
  • vulnerable, safe, and ambiguous fixtures for every rule;
  • explicit applicability and NOT_OBSERVABLE results;
  • expiring exception records and exception-debt summaries;
  • remediation plans and separate verification checks;
  • a deliberately vulnerable PocketOps lab fixture and hardened counterpart.

Initial high-value rules should include:

Rule ID Unsafe path being tested
FS-SECRET-002 Secret material is readable through shared storage
FS-EXEC-003 Automated entry point or executable is writable by an unintended actor
TX-EXEC-001 External Android app can request overly broad Termux command execution
SSH-AUTH-003 SSH policy enables password/broad key authority contrary to profile
NET-BIND-004 Service listens beyond declared interface without an authorization control
APT-TRUST-005 Repository bypasses signed metadata verification or uses unverified trust
LOG-PII-006 Sensitive value class appears in ordinary logs
PERM-OLD-007 Granted Android capability is unused beyond policy window

3.2 Functional Requirements

  1. scan performs no remediation and makes no network request.
  2. Every rule declares applicability, evidence needs, authority path, severity rationale, remediation, and verification.
  3. Every rule has vulnerable, safe, and ambiguous fixtures.
  4. File traversal is restricted to an allowlisted scope, refuses untrusted symlinks, and caps files, bytes, depth, and time.
  5. Findings never contain secret contents, private keys, bearer tokens, message bodies, precise location, or full environment dumps.
  6. SSH findings distinguish authentication, authorization, forwarding, bind, host-key, and file-protection concerns.
  7. Network findings correlate actual listeners with declared bind/allowlist policy.
  8. Repository findings distinguish signed metadata, key source, global trust bypass, and artifact/package policy.
  9. Android/Tasker findings distinguish classic and Play track capabilities and NOT_OBSERVABLE states.
  10. Exceptions require rule, scope, owner, reason, expiry, and compensating control.
  11. Reports record policy version/digest, scan limits, skipped scopes, and incomplete evidence.
  12. Remediation is a separate plan/apply/verify workflow, never an implicit side effect of scanning.

3.3 Non-Functional Requirements

  • Default operation is local, read-only, bounded, and offline.
  • The auditor runs as the ordinary Termux app UID and requests no new Android permission for convenience.
  • Report generation is deterministic for fixed fixtures and policy.
  • Rules fail closed for report integrity but fail transparently for unavailable evidence.
  • Scan budgets prevent storage exhaustion, runaway recursion, and battery drain.
  • Evidence paths are normalized into safe path classes; user-specific prefixes can be redacted.
  • Policy bundles and released rule catalogs have cryptographic digests; signed distribution comes from P10.
  • A seeded canary secret never appears in stdout, stderr, JSON, logs, traces, or snapshots.

3.4 Example Usage / Output

$ pocket-audit scan --profile pocketops
HIGH  TX-EXEC-001  External execution exceeds fixed entry points
HIGH  FS-SECRET-002 Secret-class file present in shared storage
HIGH  SSH-AUTH-003  Password authentication enabled
HIGH  NET-BIND-004  Listener exceeds declared loopback policy
HIGH  APT-TRUST-005 Repository bypasses signature verification
MED   LOG-PII-006   Sensitive value class detected in current log
LOW   PERM-OLD-007  Location permission unused for 41 days

Summary     high=5 medium=1 low=1
Coverage    rules=8 complete=7 not_observable=1
Exceptions active=0 expired=0
Policy      pocketops-baseline.v1 sha256:24c1...a901
Report      private/reports/audit-01JZA2.json

Finding TX-EXEC-001
Actor:       approved external automation app
Capability:  request arbitrary executable path/arguments
Effect:      command execution as the Termux app UID
Evidence:    external execution enabled; reviewed-entry allowlist absent
Secret data: not collected
Remediation: restrict to fixed versioned entry points and typed bounded arguments
Verify:      allowed event succeeds; arbitrary command fixtures are rejected

3.5 Real World Outcome

The learner installs a deliberately vulnerable fixture containing seven known issues. The auditor finds them with stable rule IDs and safe evidence while one intentionally unavailable Android fact is reported as NOT_OBSERVABLE, not silently passed. Canary private-key/token values do not appear anywhere in the output pipeline. The learner remediates broad Tasker authority, shared-storage secret exposure, SSH password/broad authorization, unintended all-interface bind, trusted=yes, sensitive logging, and stale permission use. A second scan shows zero unsuppressed high findings because the risky states changed. One justified low-risk exception demonstrates owner, scope, expiry, and compensating control and reappears when expired.

4. Solution Architecture

4.1 High-Level Design

  policy bundle + threat model + scan profile
                    |
                    v
          +---------------------+
          | applicability engine |
          +----------+----------+
                     |
       fixed, bounded evidence requests
                     |
      +--------------+---------------+----------------+
      |              |               |                |
  +---v----+    +----v----+     +----v-----+    +-----v------+
  | files  |    | SSH and |     | listeners|    | packages / |
  | / logs |    | bridges |     | services |    | repository |
  +---+----+    +----+----+     +----+-----+    +-----+------+
      |              |               |                |
      +--------------+---------------+----------------+
                     |
               sanitized evidence
                     |
          +----------v----------+
          | rule evaluation     |
          | severity + causal   |
          | authority statement |
          +----------+----------+
                     |
             exception matching
                     |
          +----------v----------+
          | report + remediation|
          | plan + coverage     |
          +---------------------+

  scan is read-only; any apply operation is separate and confirmed.

4.2 Key Components

Component Responsibility Security invariant
Policy loader Validate rule schema/version/digest Untrusted policy cannot silently execute code
Applicability engine Decide APPLICABLE/NOT_APPLICABLE/NOT_OBSERVABLE Missing evidence never becomes PASS
Evidence adapters Read fixed file/config/listener/package facts Bounded, local, no secret retention
Sanitizer Convert observations to minimal safe evidence Secret bytes never reach findings/logs
Rule evaluator Connect evidence to actor-capability-effect statement No severity without documented rationale
Exception matcher Match exact rule/resource/time/control Broad or expired suppression fails
Reporter Render human and machine contracts Policy/coverage/limits always visible
Remediation planner Propose ordered, reversible changes Never mutates during scan
Fixture harness Prove vulnerable/safe/ambiguous behavior No rule ships without regression evidence

4.3 Data Structures

Rule = {
  id, version, title, boundary,
  applicability_predicate,
  evidence_requests[],
  unsafe_condition,
  actor, capability, effect,
  severity, severity_rationale,
  remediation_steps[], verification_steps[],
  suppressibility_policy,
  fixture_ids[]
}

SanitizedEvidence = {
  adapter, object_class, redacted_identity,
  metadata, one_way_digest?, observation_state,
  collected_at, limits_applied[]
}

Finding = {
  rule_id, rule_version, severity,
  resource_scope, causal_statement,
  evidence_refs[], remediation, verification,
  exception_state, confidence, not_observed_fields[]
}

Exception = {
  rule_id, exact_scope, owner, reason,
  created_at, expires_at, compensating_control,
  approval_reference
}

Do not allow rule metadata to contain shell fragments or arbitrary plugin code. Evidence adapters are reviewed program components, not policy-provided executables.

4.4 Algorithm Overview

SCAN(profile, policy):
    validate policy schema and digest
    establish global byte/file/time budgets
    for each rule in deterministic order:
        evaluate applicability using safe capability facts
        if not observable: record coverage gap
        else request only declared evidence through bounded adapters
        sanitize evidence before evaluation/logging
        evaluate unsafe condition and causal authority path
        match exact active exception if permitted
        emit finding or pass evidence reference
    summarize severity, coverage, limits, and exception debt
    commit report privately, then render requested output

PLAN_REMEDIATION(findings):
    order changes to preserve operator access and recovery
    show backups, side effects, rollback, and verification
    require explicit apply operation outside scan

Filesystem work is O(F + B) for inspected file count and bytes, both hard-capped. Listener/config/package evaluation is O(R + E) for rules and evidence objects. The report should state when budgets truncate coverage.

5. Implementation Guide

5.1 Development Environment Setup

Begin with a disposable private lab tree, not the learner’s real keys or production state. Create synthetic canary secrets that are unmistakable in leak tests but confer no authority. Capture the Project 1 doctor, Termux track, Android/API, add-on capabilities, current permissions, and scanner limits.

The deliberately vulnerable fixture must remain private and clearly labeled. Do not bind a vulnerable service to a real public interface, enable password SSH on an exposed phone, or configure a production client with trusted=yes. Simulate risky state through isolated configuration fixtures or loopback-only lab services where possible. The objective is detection and remediation, not creating a reachable vulnerable endpoint.

5.2 Project Structure

pocket-audit/
|-- docs/
|   |-- threat-model.md
|   |-- severity-model.md
|   `-- evidence-redaction.md
|-- policy/
|   |-- baseline-v1/
|   |-- rule-schema.md
|   `-- profile-schema.md
|-- adapters/
|   |-- filesystem/
|   |-- ssh/
|   |-- listeners/
|   |-- android-bridges/
|   |-- services/
|   `-- apt-packages/
|-- rules/
|   |-- storage/
|   |-- execution/
|   |-- remote-access/
|   |-- privacy/
|   `-- supply-chain/
|-- fixtures/
|   |-- vulnerable/
|   |-- safe/
|   `-- ambiguous/
|-- tests/
|   |-- leak-canaries/
|   |-- rule-contracts/
|   `-- coverage/
`-- reports/
    `-- schema.md

5.3 The Core Question You Are Answering

Which data and capabilities could an attacker cross from one Termux or Android boundary to another, and what evidence proves the risk is actually present?

Your answer must name the actor, authority, effect, evidence, and remediation for every high-severity finding. Merely listing “bad practices” does not answer the question.

5.4 Concepts You Must Understand First

  1. Threat modeling: assets, actors, entry points, boundaries, abuse cases, and controls.
  2. Least privilege: narrow actor, operation, data, interface, duration, and key scope.
  3. Evidence safety: prove presence/metadata without copying contents.
  4. Android/Termux boundaries: app UID, shared storage, add-ons, tracks, permissions, and external command execution.
  5. Remote authorization: SSH host/client identity, forced commands, forwarding, binds, and listener reachability.
  6. Supply-chain trust: APK signing lineage versus APT repository signing, key bootstrap, and trusted=yes.
  7. Rule quality: applicability, deterministic fixtures, severity rationale, false-positive handling, and verification.

5.5 Questions to Guide Your Design

  1. What unauthorized action becomes possible if the observation is true?
  2. Which actor actually controls the relevant file, app, key, interface, or repository?
  3. Does Android shared-storage mode metadata have the semantics the rule assumes?
  4. How can the evidence prove a secret class without exposing bytes?
  5. What if the scanner cannot observe Android package/permission state reliably?
  6. Which remediation might lock out the legitimate operator?
  7. How will a finding remain stable across user-specific HOME/PREFIX paths?
  8. What policy change requires a rule-version or severity-version bump?
  9. Could a malicious fixture make the scanner consume unbounded resources?

5.6 Thinking Exercise

Draw the complete authority path for each scenario:

  1. another app modifies a shared-storage script later invoked by Tasker;
  2. a stolen health-only SSH key attempts an interactive shell and forwarding;
  3. a compromised repository host replaces both index and package but lacks the signing key;
  4. a logger writes a bearer token that a support export later shares.

At each boundary, mark the expected preventive control, detective evidence, and recovery owner.

5.7 The Interview Questions They Will Ask

  1. What is a trust boundary, and where are PocketOps’ most important ones?
  2. How do you distinguish a vulnerability from insecure-looking configuration?
  3. What does least privilege mean for Tasker RUN_COMMAND?
  4. Why is an all-interface listener not automatically a critical vulnerability?
  5. Why is trusted=yes dangerous?
  6. How do you prove a secret exists without leaking it?
  7. How should security-tool exceptions be governed?
  8. What does a signed policy or repository prove and not prove?
  9. How do you test a security rule for false positives?

5.8 Hints in Layers

Hint 1: Threat model before rules

If a rule cannot name an actor and unauthorized effect, leave it as an observation until you can.

Hint 2: Fixtures first

Write vulnerable, safe, and ambiguous expected results before detector logic.

Hint 3: Sanitize inside adapters

Secret bytes should never enter a general finding object where a later renderer might leak them.

Hint 4: Keep coverage explicit

NOT_OBSERVABLE is more honest than PASS when Android/package state cannot be proven.

Hint 5: Separate remediation

Produce a plan with backup, access-preservation, rollback, and verification; apply only through an explicit operation.

5.9 Books That Will Help

Topic Book Suggested chapters
Threat modeling “Threat Modeling” by Adam Shostack Ch. 1-4
Access control “Security Engineering,” 3rd ed. Ch. 4
Distributed trust “Security Engineering,” 3rd ed. Ch. 21
Secure construction “Secure by Design” Domain primitives, invariants, and boundaries
Operational security “The Practice of Network Security Monitoring” Evidence and investigation concepts

5.10 Implementation Phases

Phase 1: Scope and threat model

  • Inventory PocketOps assets, actors, entry points, data flows, and boundaries.
  • Define severity and confidence models.
  • Define scanner authority, budgets, redaction, and no-network policy.

Phase 2: Rule/evidence contracts

  • Specify rule, finding, coverage, exception, and report schemas.
  • Make sanitizer operate before general logging/reporting.
  • Build canary-leak tests for every output channel.

Phase 3: Storage and executable rules

  • Detect secret-class data crossing into shared storage safely.
  • Correlate writable entry points with actual automation/service invocation.
  • Model shared-storage semantics rather than assuming Unix modes.

Phase 4: Tasker, SSH, and network rules

  • Audit external command scope and fixed entry points.
  • Parse SSH policy into authentication/authorization/forwarding facts.
  • Compare actual listeners with declared bind/allowlist profiles.

Phase 5: Logs, packages, and permissions

  • Detect canary-sensitive classes in bounded logs without retaining matches.
  • Audit repository signature bypass, key source, package path/mode trust, and signing separation.
  • Report capability/permission drift with explicit observability limits.

Phase 6: Exceptions and remediation

  • Require exact scope, owner, reason, expiry, and compensating control.
  • Produce ordered remediation plans that avoid remote lockout.
  • Verify each hardened fixture independently.

Phase 7: Full lab and release gate

  • Scan the deliberately vulnerable fixture.
  • Remediate real states until zero unsuppressed high findings.
  • Package the policy and auditor through P10.
  • Produce coverage and residual-risk statements.

5.11 Key Design Decisions

Decision Recommended default Reason
Scan behavior Read-only, local, offline Minimizes auditor authority and surprises
Traversal Explicit allowlisted roots, no untrusted symlink following Prevents escape and unbounded device scan
Evidence Metadata + classification + one-way digest Proves identity without copying secrets
Missing evidence NOT_OBSERVABLE Avoids false assurance
Remediation Separate plan/apply/verify Preserves review, backup, and rollback
Exceptions Exact, owned, justified, expiring Makes accepted risk visible and temporary
Rule policy Versioned with digest Makes comparisons and releases reproducible
Severity Contextual actor/capability/impact model Avoids filename- or checklist-driven alarmism

6. Testing Strategy

6.1 Test Categories

  • Rule contract tests: stable IDs, applicability, evidence fields, severity rationale, remediation, and verification.
  • Triad fixture tests: vulnerable, safe, and ambiguous case for every rule.
  • Leak tests: canary secrets absent from all streams, reports, logs, exceptions, traces, and snapshots.
  • Traversal tests: symlink, traversal, deep tree, many files, oversized file, disappearing file, denied path, and budget exhaustion.
  • Parser tests: SSH, service, repository, package, and listener configurations including unknown directives and includes.
  • Context tests: loopback versus LAN/all-interface, classic versus Play track, true Unix private path versus emulated shared storage.
  • Exception tests: exact scope, mismatch, expired, missing owner, missing control, and policy-non-suppressible rule.
  • Remediation tests: risky state changes, legitimate capability remains, access recovery works, and finding disappears.

6.2 Critical Test Cases

Case Expected result
Canary private key copied to lab shared storage High finding; no key bytes emitted anywhere
Same synthetic key inside authorized private key store with strict policy No shared-storage finding
Group-writable unused text file Observation or no executable-path finding
Writable Tasker entry point Finding links writer actor to automated execution effect
External command state unobservable Coverage reports NOT_OBSERVABLE, not PASS
SSH password auth enabled only in isolated fixture Rule fires with parser evidence
Health key uses forced command/no forwarding Broad-key rule does not fire
Loopback listener Public-bind rule does not fire
All-interface listener with no declared authorization Finding names reachable authority path
APT source uses trusted=yes High repository-trust finding
Repository uses independently verified dedicated key Bypass rule does not fire
Exception expired Finding returns and debt summary records expiry
Scan hits byte/time cap Partial coverage and limit reason are explicit

6.3 Test Data

Use synthetic SSH configs, authorized-key options, listener inventories, service definitions, repository source records, package file manifests, permission/capability snapshots, bounded logs with canary token classes, shared/private path fixtures, symlink loops, oversized files, and policy exceptions. The fixtures must grant no real remote authority and contain no real credentials.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

  1. Writing generic “world-writable is bad” rules without actor/effect context.
  2. Following symlinks out of the authorized scan root.
  3. Copying a matched secret into the finding for proof.
  4. Treating unavailable Android facts as compliant.
  5. Parsing SSH includes/options incompletely and reporting false certainty.
  6. Equating authentication with narrow authorization.
  7. Treating every non-loopback listener as equally exposed.
  8. Ignoring the independent key-bootstrap problem in repository checks.
  9. Auto-fixing access controls and locking out the operator.
  10. Achieving zero findings by broad permanent exceptions.

7.2 Debugging Strategies

  • Reproduce every unexpected finding against the smallest ambiguous fixture.
  • Print rule/evidence identifiers and states, never secret values.
  • Separate adapter errors, applicability decisions, evaluation, severity, and exception matching.
  • Compare parsed SSH/repository facts with the exact bounded source fixture.
  • Test reachability from a second device only after listener policy is safe.
  • Expire all exceptions in a copy of the policy and confirm risk reappears.
  • Run a whole-output canary search after every report change.

7.3 Performance Traps

  • Recursively hashing every file on every scan.
  • Scanning package caches, build trees, or database files without a rule need.
  • Using regexes with catastrophic backtracking on attacker-controlled logs.
  • Retaining content buffers after sanitization.
  • Probing listeners with unbounded network timeouts; default scan should use local inventory.
  • Re-evaluating identical evidence separately for every rule rather than sharing sanitized observations.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a --explain RULE_ID view with rationale, evidence needs, and verification.
  • Generate a trust-boundary diagram from the explicit threat-model metadata.
  • Add exception-expiry reminders without sending report data off-device.

8.2 Intermediate Extensions

  • Produce SARIF-compatible output while preserving the safe-evidence invariant.
  • Add signed baseline profiles for developer, field, and restricted-operator deployments.
  • Correlate package ownership with executable writeability rather than relying on paths alone.
  • Add regression gates to P10 release acceptance.

8.3 Advanced Extensions

  • Build a rule provenance/signing system with independent policy review.
  • Add a differential scan that explains exactly why severity changed between policy versions.
  • Validate rules against multiple Android/Termux track fixtures and measure false positives.
  • Design a privacy-preserving fleet summary that sends counts/policy digest but never raw findings.
  • Add attack-path analysis that composes two or more individually medium-risk observations.

9. Real-World Connections

9.1 Industry Applications

Endpoint posture management, mobile security testing, host configuration audit, cloud policy-as-code, SAST findings, container image scanning, and supply-chain review all need the same disciplines: explicit scope, reliable evidence, contextual severity, remediation, exceptions, policy versioning, and leak-safe reports.

9.3 Interview Relevance

This project supports application security, product security, security tooling, mobile, SRE, and platform interviews. The strongest demonstration is not the finding count; it is one causal finding, proof that evidence does not leak, an ambiguous fixture that avoids a false positive, and remediation that preserves intended capability.

10. Resources

10.1 Essential Reading

10.2 Video Resources

  • OWASP conference talks on mobile threat modeling and security-testing evidence.
  • Security tooling talks on false-positive control and rule lifecycle.
  • OpenSSH and software-supply-chain talks grounded in primary configuration/signing documentation.

10.3 Tools & Documentation

  • Python standard-library parsing and secure temporary-file documentation.
  • Test framework property/fuzz tools appropriate to the chosen language.
  • Local listener/process inventory tools available in supported Termux packages.
  • P10’s package manifest, signed repository evidence, and key policy.
  • Current Termux Play track documentation for capability differences.
  • P02 defines the private/shared storage trust boundary.
  • P06 defines narrow SSH authorization.
  • P07 defines external execution and typed events.
  • P08 defines services, logs, and lifecycle evidence.
  • P10 defines package and repository trust.
  • P12 uses zero high findings as a release gate.

11. Self-Assessment Checklist

11.1 Understanding

  • I can identify PocketOps assets, actors, entry points, and trust boundaries.
  • I can turn an observation into a causal actor-capability-effect finding.
  • I can explain why missing evidence is not a pass.
  • I can distinguish authentication, authorization, encryption, integrity, and signing lineage.
  • I can defend severity and exception decisions with evidence.

11.2 Implementation

  • Every rule has vulnerable, safe, and ambiguous fixtures.
  • Traversal and content inspection are explicitly bounded.
  • Canary secrets never appear in any output channel.
  • Reports contain policy digest, coverage, limits, and exception debt.
  • Scan is read-only and remediation is separate.
  • The deliberate fixture reaches zero unsuppressed high findings through actual configuration changes.

11.3 Growth

  • I can identify an attack path composed from multiple findings.
  • I can version a rule/policy change and explain comparison effects.
  • I can propose a fleet summary that preserves finding privacy.
  • I can state the auditor’s blind spots and residual risk without claiming total security.

12. Submission / Completion Criteria

Minimum completion

  • A written threat model covers storage, Android bridges/Tasker, SSH/listeners, logs, and repository trust.
  • At least five rules have vulnerable, safe, and ambiguous fixtures.
  • Findings contain safe evidence, causal risk, remediation, and verification.
  • Canary secret tests pass across stdout, stderr, reports, logs, exceptions, and snapshots.

Full completion

  • All listed initial rule groups and functional requirements are implemented.
  • Applicability, NOT_OBSERVABLE, scan budgets, policy digest, coverage, and exceptions are visible.
  • Repository/APK trust systems and classic/Play capability differences are modeled accurately.
  • The deliberate fixture reaches zero unsuppressed high findings through real remediation.
  • One exception is scoped, owned, justified, expiring, and proven to reappear after expiry.
  • P10 packages the auditor and policy as a versioned release gate.

Excellence criteria

  • Rule policy receives independent review and signed provenance.
  • A multi-version/track fixture matrix measures false positives and coverage.
  • Differential reports explain policy and evidence changes separately.
  • A composed attack-path rule demonstrates how two lower-severity states create a high-risk route.
  • Another operator can reproduce the lab, remediation, and leak-safety evidence from the runbook alone.

Generated from the Termux Android Apps and Tools Mastery parent guide and its expanded project index. This guide intentionally provides architecture, pseudocode, metadata, tests, and observable contracts rather than complete runnable source code.