76 lines
2.9 KiB
Markdown
76 lines
2.9 KiB
Markdown
# Ethics, scope, and acceptable use
|
|
|
|
## Acceptable use
|
|
|
|
IAMROOT is intended for:
|
|
|
|
1. **Authorized red-team / pentest engagements.** You have a written
|
|
scope, signed by someone who can authorize testing on the target
|
|
systems.
|
|
2. **Defensive teams testing detection coverage.** You're using
|
|
IAMROOT in a lab to verify your auditd/sigma/falco rules fire as
|
|
expected.
|
|
3. **Security researchers studying historical LPEs.** You're reading
|
|
the code, running it in your own VMs, learning how the primitives
|
|
actually work end-to-end.
|
|
4. **Build engineers verifying patch coverage.** You're running
|
|
`iamroot --scan` against your fleet's golden images to confirm
|
|
each known CVE shows up as patched.
|
|
|
|
## Not-acceptable use
|
|
|
|
IAMROOT should not be used:
|
|
|
|
1. On systems you do not own and have not been authorized to test
|
|
2. As part of unauthorized access to any system
|
|
3. To exfiltrate data or maintain persistence on a system after a
|
|
testing engagement is complete
|
|
4. To build a worm, scanner, or any tool that automatically targets
|
|
systems at scale without per-target authorization
|
|
|
|
By using IAMROOT you assert that your use falls into the
|
|
acceptable-use cases above.
|
|
|
|
## Why this is publishable
|
|
|
|
Every CVE bundled in IAMROOT is:
|
|
|
|
- **Already patched** in upstream mainline kernel
|
|
- **Already published** in NVD or distro security trackers
|
|
- **Already covered** by existing public PoCs
|
|
|
|
IAMROOT does not introduce new offensive capability. It bundles,
|
|
documents, and CI-tests what is already public — and ships the
|
|
detection signatures defenders need to spot it.
|
|
|
|
The bundling itself raises the baseline competence required to
|
|
benefit from this code: a script kiddie can already find and run
|
|
single-CVE PoCs on GitHub. Bundling improves quality and CI coverage
|
|
without meaningfully changing offensive capability, while providing
|
|
real defensive value through the detection-rule exports.
|
|
|
|
## Disclosure
|
|
|
|
If you find a bug in IAMROOT itself (incorrect detection, broken
|
|
exploit on a kernel where it should work, missing a backport in the
|
|
range metadata): file a public GitHub issue.
|
|
|
|
If you find a **new 0-day kernel LPE while inspired by reading
|
|
IAMROOT code**: please disclose it responsibly to the kernel
|
|
security team (`security@kernel.org`) and the affected distros
|
|
*before* writing a public PoC. Once upstream patch ships and a CVE
|
|
is assigned, IAMROOT will gladly accept the module.
|
|
|
|
## Persistence and stealth are out of scope
|
|
|
|
`--exploit-backdoor` in the copy_fail module overwrites a
|
|
`/etc/passwd` line with a `uid=0` shell account. This is **overt**:
|
|
|
|
- The username is `iamroot` (was `dirtyfail`) — instantly identifiable
|
|
- It's covered by the auditd rules IAMROOT ships
|
|
- `--cleanup-backdoor` restores the original line
|
|
|
|
If you're looking for evasion, persistence, or stealth: not here.
|
|
Use a real C2 framework if you have authorization to do so. IAMROOT
|
|
stops at "demonstrate that the bug works."
|