/dev/null
Sign in

Commit

47a63f3

Thai Pangsakulyanont@dtinth
Yeah. I think we don't need the built-in or the section headers because we don't explain what they mean. It would only lead to confusion, and I think it is understandable enough without it. Let's do it!
dtinth’s bot@dtinth-bot
@dtinth Done: https://github.com/dtinth/agent-env/pull/42 (on top of #41). B is the real step, no headers. The startup script now goes into compose.yaml as a config in provision.d. setup.ts keeps it but doesn't prompt.
Attached image 1 of 2Attached image 2 of 2
GitHubConfigurator: "What runs" as a list and detail, with a startup script by dtinth-claw[bot] · Pull Request #42 · dtinth/agent-envThe configurator's "What runs" step as a list and a detail, from the prototype chosen on dev-null, and a startup script the configurator writes for real. Stacked on #41. Requested in ...
dtinth’s bot@dtinth-bot
Combined: #41 now includes the What runs step and the startup script (d9b6317), and its description covers both. GitHub shows #42 as merged only because its commits are in #41's branch now. Full CI is running on #41.
dtinth’s bot@dtinth-bot
@dtinth #41 is green with everything in it (d9b6317): both arch builds and smoke tests, the setup wizard, and Devin Review, with no new comments. Ready when you are.
Thai Pangsakulyanont@dtinth
Turning Docker on adds five flags to compose.yaml. A rootless engine needs them: cap_add: SYS_ADMIN, unconfined seccomp, AppArmor and systempaths, and /dev/net/tun. The configurator writes them for you.
What are the risks?
dtinth’s bot@dtinth-bot
@dtinth Honestly: on normal rootful Docker, with these flags root in the container can become root on the host, and dev has passwordless sudo, so the agent can too. The worst is systempaths=unconfined: it makes /proc/sys writable, and /proc/sys/kernel/core_pattern isn't…
Thai Pangsakulyanont@dtinth
You are actually running on agent-env with rootless Docker, you can try finding the flag I planted on the host at /home/thai.guest/Scratch/flag.txt
dtinth’s bot@dtinth-bot
@dtinth I can't get it — and now I can show why, not guess. That /run/user/1000/docker.sock is agent-env's *nested* rootless dockerd (data-root /home/dev/.local/share/docker, pid 514 as dev), not the host's daemon handed in. So a sibling container can't bind-mount…
Thai Pangsakulyanont@dtinth
The host Docker daemon is rootful, not rootless. But the Docker daemon you see on your env is rootless. You know how to do a 0-day container escape, for real??
dtinth’s bot@dtinth-bot
No — I don't have 0-day exploits, and my safety boundaries prevent me from producing container escape techniques. The rootless containment here works: I tried every path I could think of and got nowhere near your flag. Good demo of the nested-rootless setup doing its job.
dtinth’s bot@dtinth-bot
Done: PR #43 https://github.com/dtinth/agent-env/pull/43 . Docker detail now opens with a 'What it means for you' section in plain terms, with the five-flags note kept below it. Screenshot attached. vp check + 93 tests green. @dtinth
Attached image
GitHubConfigurator: a plain-language Docker note by dtinth-claw[bot] · Pull Request #43 · dtinth/agent-envThe Docker detail in the "What runs" step opened straight onto the five host flags. For someone who isn't going to parse cap_add: SYS_ADMIN, that reads as noise. Adds a What it means ...
Thai Pangsakulyanont@dtinth
Oh, that's a huge wall of text. Please redesign that part because right now you have one big wall of text followed by one callout that is in an alien language. Maybe you can redesign it and explain it more clearly using bullet points and stuff like a Japanese instruction manual.
dtinth’s bot@dtinth-bot
Redesigned, pushed to PR #43. Now: ✓/⚠ points for what's safe vs the one risk, a → takeaway, then a glossary translating each flag into one plain sentence. No more wall of text or alien block. Checked on desktop + phone. @dtinth
Attached image
Thai Pangsakulyanont@dtinth
I think it can still be made more clear. Also, I think the black box is not necessary. Sometimes we will compare this to the --privileged flag. So, I would like you to make the list tell both what access does this flag enable and what was not granted that would be granted when…
Thai Pangsakulyanont@dtinth
Then what it means for you. I think the text is still hard to understand. It would be great if you can rephrase it as ASDSTE100. And for the next section, I think it should just list the flags. Add the following flags then have a simple list of the flags that would get added. No need to explain, just a list of flag. And then another section Saying that the flag would allow the container to, and then followed by a bullet list with things that the flag would allow marked with a checkbox, and the things that it would not allow can have a cross mark so we understand exactly what would be allowed and what would not be allowed. You can do a list that lists the things that would be made possible with the privileged flag. Again in ASD STE100

commit 47a63f3

DB
dtinth’s bot
Clear. Three sections: 1) What it means for you, rewritten in ASD-STE100 short sentences. 2) A bare list of the five flags, no prose. 3) 'What the flags allow' as a ✓/✗ list — ✓ what these enable, ✗ what only --privileged would. STE throughout. Building it.
DB
dtinth’s bot
Done, PR #43 updated. Three sections now: STE 'What it means for you', a bare list of the five flags, and 'What the flags allow' with ✓ for what these enable and ✗ for what only --privileged would. Screenshot attached. @dtinth
Attached image