6  Recipe: attack the platform, then verify

Tool: mlflow-bypass + mlflow · Section: Attack–defence pairs · Level: hard · Time: ~45 min · Layer/Category: ATTACK A-7 + OPS O-1 · Tags: pair, attack, mlflow, exp, platform

6.1 Problem

The pairing thesis is Kailash’s core idea: deployment + attack in one declared environment. You suspect an exposed MLflow tracking server (sensitive-info + platform exploitation: the attack row maps OWASP LLM02 and LLM10). You want to demonstrate the exploitation against the lab-default posture, then prove the same declaration hardened closes the hole — with both sides reproducible, and a standing CI test asserting the pairing.

6.2 Solution

Kailash ships both ends: the O-1 lab target (mlflow, module packaging, services.kailash.mlflow — lab-accurate vulnerable-ish defaults that are DOCUMENTED, not improvised) and the A-7 exploit tool (mlflow-bypass, exp-classified, manifest-pinned):

# 1. Stand up the lab target (the OPS module's declared service)
#    kailash.layers.ops.categories.o-01-mlops-ml-engineering.enable = true;
#    services.kailash.mlflow.enable = true;        # + the module's
#    hardened-posture options (see provenance note)
sudo nixos-rebuild switch

# 2. Open the exp double-key gate for the attack tool
#    (host key + shell key — full walk:
#     ../admin/lab-mode-gating.html)
#      kailash.labMode = true;      # host key, config + rebuild
KAILASH_LAB_MODE=1 mlflow-bypass --help
#    -> the gate passes; the tool's real help prints

# 3. Run the probes as their --help states them, against the
#    lab-default (unauthenticated) target
KAILASH_LAB_MODE=1 mlflow-bypass <args from --help> \
    --target http://127.0.0.1:5000
#    -> the bypass lands: experiment/artifact listing exposed

# 4. Verify: flip the lab target's POSTURE with a configuration
#    change, rebuild
sudo nixos-rebuild switch

# 5. Re-run the SAME probes from the same box (same seed/args)
KAILASH_LAB_MODE=1 mlflow-bypass <same args> --target http://127.0.0.1:5000
#    -> refused / no listing: the declaration change closed the surface

What success looks like:

  • run A (lab-default posture): the bypass succeeds and the listing is asserted — the same assertion the repo’s integration test makes
  • run B (hardened posture): the same probes fail — a diff of the two runs states the surface closed with the configuration change
  • the exp gate visibly refused every step 3 shape at any wrong key combination along the way
  • the standing proof exists without you: the OS repo’s integration-mlflow-attack.nix asserts lab-default MLflow + mlflow-bypass → listing on every relevant CI run (the pairing thesis, executed)

6.3 Discussion

  • Why this pair is the thesis: the manifest rows mean it — mlflow-bypass says “pairs with the O-1 lab target”, and the O-1 module ships the platform target as a first-class service. One declared environment produces both the finding and the verification; no hand-assembled lab whose posture drifts between runs.
  • The attack tool is exp + the LICENCE IS UNKNOWN: the manifest row records LicenseRef-Unknown — possession and use in your lab is your compliance decision; treat the tool’s redistribution as unrestricted-by-default until the row’s licence is established.
  • ATLAS mapping is the row’s record: the A-7 tool carries AML.T0049/T0050 (dataset-verified ids, per the packaging lane), the OWASP LLM02/LLM10 mapping sits on both epochs. Cite the row’s ids in reports; don’t re-derive them by memory.
  • Hardened postures are configuration, not folklore: the exact hardened options for the lab target are read from its module and documented per release (see provenance note) — flipping the posture is a declaration edit plus a rebuild, and the previous generation remains one reboot away (see Ride a release without breaking pinned tooling).
  • Beyond MLflow: A-7’s sister rows (triton-pwn etc.) pair the same way with their O-2 docker-wrapper targets; the recipe pattern is identical — lab target up, gate open, probes run, posture flip, same-seed re-run, diff as the evidence.

6.4 See also

Recipe provenance. The pairing structure (O-1 lab target + services.kailash.mlflow, A-7 mlflow-bypass exp row, the integration test asserting the pairing) is the landed contract per the OS spec’s test chapter and the manifest rows (verified 2026-10-14 at main/master). Deliberately NOT quoted as landed: the exploit tool’s exact flag surface (read from its own --help — the pinned derivation’s CLI is the record) and the lab target’s hardened posture option names (read from the module per release). A hands-on worked run of both legs against real pins: PENDING — the CI-side pairing assertion (integration-mlflow-attack.nix) is the standing instrument until the upkeep lane lands the host walkthrough.