Conversation
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2222795 to
fb4dac1
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fb4dac1e2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5c01ea7ef8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb6cb2e209
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c7faf4182e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 10c05fb703
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f4e7ca98ce
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b709b28c6e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Select Podman for exact and bounded-range mapping profiles, define exclusive per-installation private mappings and the trusted supervisor capability boundary, and record identity-policy, sandbox, isolation, capability, and lifecycle conformance requirements before product integration. Require Docker Engine rejection, reject external bind mounts until safe input and ownership contracts exist, and require identifiable seccomp-policy evidence while deferring public schema and production runtime behavior to later reviewed slices.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d8f2ef9816
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | --- | --- | --- | --- | --- | | ||
| | ID-01 | Every mapped identity has exclusively delegated subordinate host authority only; it does not alias host root, a local or NSS-provided host principal, or a subordinate range delegated to another host principal. | 1 | Host-side mapping inspection and authoritative collision checks against the host identity inventory and every other subordinate UID/GID delegation, plus explicit collision-failure cases and an in-container identity probe for each profile. | Unproven; repeated conformance probe pending | | ||
| | ID-02 | The trusted supervisor can perform every required declared transition and rejects mapped-but-undeclared UIDs, GIDs, and supplementary groups; a separate raw bounded-range mechanism probe permits representative other in-range transitions. | 1 | Positive declared-identity and negative mapped-but-undeclared tests through the production supervisor policy, plus an independently identified raw range-mechanism probe. | Unproven; repeated conformance probe pending | | ||
| | ID-03 | Exact mappings reject every unmapped transition; bounded ranges reject every out-of-range transition; capability-dropped children cannot change identity or regain authority through set-ID or file-capability execution. | 1 | Profile-specific boundary and post-drop tests for `setuid`, `setreuid`, `setresuid`, `setfsuid`, `setgid`, `setregid`, `setresgid`, `setfsgid`, `setgroups`, set-user/group-ID execution, and file-capability execution. | Unproven; repeated conformance probe pending | |
There was a problem hiding this comment.
When the supervisor starts with privileged or runtime-required supplementary GIDs and changes only the child's UID/primary GID before dropping capabilities, all listed transition and post-drop setgroups checks can pass while the child retains undeclared group access. The fresh evidence is that the amended rows reject requested mapped-but-undeclared groups but never inspect inherited membership; require each child's final Groups: vector to contain exactly its declared supplementary groups before untrusted execution.
Useful? React with 👍 / 👎.
| | ID-01 | Every mapped identity has exclusively delegated subordinate host authority only; it does not alias host root, a local or NSS-provided host principal, or a subordinate range delegated to another host principal. | 1 | Host-side mapping inspection and authoritative collision checks against the host identity inventory and every other subordinate UID/GID delegation, plus explicit collision-failure cases and an in-container identity probe for each profile. | Unproven; repeated conformance probe pending | | ||
| | ID-02 | The trusted supervisor can perform every required declared transition and rejects mapped-but-undeclared UIDs, GIDs, and supplementary groups; a separate raw bounded-range mechanism probe permits representative other in-range transitions. | 1 | Positive declared-identity and negative mapped-but-undeclared tests through the production supervisor policy, plus an independently identified raw range-mechanism probe. | Unproven; repeated conformance probe pending | | ||
| | ID-03 | Exact mappings reject every unmapped transition; bounded ranges reject every out-of-range transition; capability-dropped children cannot change identity or regain authority through set-ID or file-capability execution. | 1 | Profile-specific boundary and post-drop tests for `setuid`, `setreuid`, `setresuid`, `setfsuid`, `setgid`, `setregid`, `setresgid`, `setfsgid`, `setgroups`, set-user/group-ID execution, and file-capability execution. | Unproven; repeated conformance probe pending | | ||
| | ID-04 | Two installations using the same container IDs have distinct host mappings plus distinct PID and IPC namespaces; they cannot observe, signal, or ptrace each other's processes, use each other's System V shared-memory, semaphore, or message-queue objects, or read each other's private state. | 1 | Concurrent two-workload probe with host mapping, PID-namespace, and IPC-namespace inspection plus negative process visibility, signaling, ptrace, System V IPC, and private-state access tests. | Unproven; repeated conformance probe pending | |
There was a problem hiding this comment.
When workloads have distinct IPC namespaces but accidentally share a /dev/shm mount, every newly added System V probe can pass while named POSIX shared-memory and semaphore objects remain mutually accessible. The fresh evidence is that amended ID-04 now enumerates only System V IPC despite promising isolation from all IPC objects; also require private /dev/shm inspection and negative shm_open/sem_open probes.
Useful? React with 👍 / 👎.
| | RV-01 | Revocation makes ordinary operations fail closed without mutating retained storage or releasing its mapping. | 1 | Revocation and recovery tests with retained owned data. | Unproven; revocation not designed | | ||
| | HB-01 | Host bootstrap is explicit, auditable, idempotent, validates that its delegated IDs are exclusive and non-overlapping, and enables later user-level operation without host root. | 1 | Repeated bootstrap, successful user operation, and failures for absent or inconsistent preparation, collisions with local or NSS-provided host principals, overlap with another principal's subordinate delegation, and an identity inventory whose completeness cannot be established. | Unproven; bootstrap not designed | | ||
| | SB-01 | No workload uses privileged mode or gains host-root authority. | 1 | Runtime inspection plus negative host-authority tests. | Unproven; repeated conformance probe pending | | ||
| | SB-02 | The approved seccomp profile is explicitly selected and identifiable in the resolved and effective runtime policy; application processes have `NoNewPrivs: 1` and seccomp filter mode (`Seccomp: 2`); syscalls the approved profile must block fail; the container root filesystem is read-only except for declared writable storage; and namespaces, devices, mounts, and network attachment match declared policy, with no host control socket, undeclared path, or peer-reachable network. | 1 and 2 | Resolved-policy and host/runtime inspection through the supported Podman path plus negative approved-policy syscall, path, cross-workload TCP, and cross-workload UDP tests through supported Reploy interfaces. | Unproven; baseline checked by one-off probe; repeated conformance pending | |
There was a problem hiding this comment.
For a production Podman workload on a host that supports limits, this row can pass without any process, memory, CPU, temporary-storage, or output bound, allowing an untrusted workload to exhaust host resources. The fresh evidence is that amended SB-02 adds seccomp, NoNewPrivs, and read-only-root checks but still omits the application-runtime resource policy required by docs/CONTROLLED_SESSION_DESIGN.md:480-481; add resolved-policy inspection and exhaustion tests for those bounds.
Useful? React with 👍 / 👎.
| - Can the generated app control script stay identical across Docker Engine, | ||
| Docker Desktop, Colima/Lima, and VM-backed runtimes? | ||
|
|
||
| ### Isolated Multi-Identity Workloads |
There was a problem hiding this comment.
This adds a user-visible security contract and advertises the planned Podman-only capability in the active future-directions documentation, but the commit contains no release-note fragment under .changes/unreleased/. Add a Docs, Security, or other configured Changie fragment so the documentation change appears in the generated changelog.
AGENTS.md reference: AGENTS.md:L7-L13
Useful? React with 👍 / 👎.
Select Podman for exact and bounded-range mapping profiles, define exclusive per-installation private mappings and the trusted supervisor capability boundary, and record identity-policy, sandbox, isolation, capability, and lifecycle conformance requirements before product integration.
Require Docker Engine rejection, reject external bind mounts until safe input and ownership contracts exist, and require identifiable seccomp-policy evidence while deferring public schema and production runtime behavior to later reviewed slices.