Name: competition-kernel-container-escape
Author: zhaoxuya520

Imported from zhaoxuya520/reverse-skill (CTF-Sandbox-Orchestrator/competition-kernel-container-escape/SKILL.md). Install upstream with npx skills add zhaoxuya520/reverse-skill --skill competition-kernel-container-escape. Copyright stays with the author.

Competition Kernel Container Escape

Use this skill only as a downstream specialization after $ctf-sandbox-orchestrator is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to $ctf-sandbox-orchestrator first.

Use this skill when the decisive step is proving a boundary crossing between containerized context and host or higher-privilege kernel context.

Reply in Simplified Chinese unless the user explicitly requests English.

Quick Start

Map runtime isolation first: namespaces, cgroups, seccomp, capabilities, LSM, and mount boundaries.
Separate exploit prerequisite, primitive, and boundary-crossing proof.
Record kernel version, config hints, runtime options, and reachable syscall surface.
Keep instrumented observations separate from pristine challenge path.
Reproduce one minimal primitive-to-boundary-crossing chain.

Workflow

1. Map Isolation And Kernel Surface

Record namespace map, cgroup mode, capabilities, seccomp profile, AppArmor or SELinux state, mounted filesystems, and runtime sockets.
Note kernel version, distro build hints, module exposure, and container runtime behavior.
Keep host and container observations linked to exact node and context.

2. Prove Exploit Primitive And Crossover

Show controllable input, trigger condition, affected object, and observable kernel or runtime state change.
Capture before and after identity, namespace, mount, or process visibility to prove boundary crossing.
Distinguish crash-only behavior from stable capability gain.

3. Reduce To Decisive Escape Chain

Compress to: prerequisite state -> primitive trigger -> boundary crossing evidence -> resulting host-level capability.
State whether root cause is kernel vulnerability, runtime misconfiguration, capability overgrant, or namespace leak.
If path relies mostly on credential replay after initial foothold, hand off to Linux credential pivot skill.

Read This Reference

Load references/kernel-container-escape.md for isolation checklist, primitive checklist, and parity guidance.

What To Preserve

Kernel and runtime context, capability set, seccomp or LSM state, and namespace map
Primitive trigger data, boundary crossing evidence, and resulting capability
One minimal reproducible chain from container context to host-relevant effect

Install competition-kernel-container-escape and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "zhaoxuya520-reverse-skill-competition-kernel-container-escape", "kind": "skill", "name": "competition-kernel-container-escape", "description": "Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for kernel attack surface, namespace and cgroup boundaries, container isolation assumptions, syscall paths, and escape primitive verification. Use when the user asks to analyze container-to-host escape paths, kernel exploit prerequisites, namespace crossover, capability misuse, or prove whether an exploit primitive crosses the sandbox boundary. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.", "publisher": "zhaoxuya520", "version": "1.0.0", "capabilities": { "domains": [ "math" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for kernel attack surface, namespace and cgroup boundaries, container isolation assumptions, syscall paths, and escape primitive verification. Use when the user asks to analyze container-to-host escape paths, kernel exploit prerequisites, namespace crossover, capability misuse, or prove whether an exploit primitive crosses the sandbox boundary. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/zhaoxuya520/reverse-skill", "path": "CTF-Sandbox-Orchestrator/competition-kernel-container-escape/SKILL.md", "ref": "HEAD", "url": "https://github.com/zhaoxuya520/reverse-skill/blob/HEAD/CTF-Sandbox-Orchestrator/competition-kernel-container-escape/SKILL.md", "key": "zhaoxuya520/reverse-skill/CTF-Sandbox-Orchestrator/competition-kernel-container-escape/SKILL.md" } }, "instructions": "# Competition Kernel Container Escape\n\nUse this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.\n\nUse this skill when the decisive step is proving a boundary crossing between containerized context and host or higher-privilege kernel context.\n\nReply in Simplified Chinese unless the user explicitly requests English.\n\n## Quick Start\n\n1. Map runtime isolation first: namespaces, cgroups, seccomp, cap", "cost": { "context_tokens": 603 } }

competition-kernel-container-escape

About