morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4325] [Design] Decide isolated runtime authority for FACT backend REST acceptance #1718

New issue

Open

opened 2026-10-16 21:09:24 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:09:24 +00:00

Owner

Originally created by @dandgabr on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4325

Before submitting

I searched open and closed issues and pull requests for a related discussion.
I understand that unresolved contribution scope and authority questions block integration.
This discussion contains no credentials, private samples, or sensitive target data.

Decision needed

Should live FACT REST acceptance be allowed to start the pinned backend against an independently isolated disposable runtime API? This is a pending decision, not an approval or a request to expose the user’s runtime socket.

Context and evidence

Existing decision: https://github.com/morluto/rea/issues/4110 defines REST reads and explicit consuming collection, but does not establish an isolated runtime API authority. Its2026-10-15 comment records backend startup blocked by absent Docker socket. This draft does not authorize startup or change settled route classifications.

Requested decision: permit only test-infrastructure provisioning of a disposable FACT backend at source54aed90bacb13c484404018101527c72d0bff6c5 with a separately provisioned rootless identity/store/API or disposable VM. No human Podman/Docker socket or user container namespace/store/home is accessible. Source mount is pinned/read-only; database, firmware storage and runtime state are private; service network internal, REA endpoint literal loopback. A store under the same identity alone does not prove inaccessible host paths; require an enforced filesystem/user boundary and child-container restrictions before startup.

Acceptance operations: status, statistics, firmware/file lookup, gaps, object detail, seeded dummy result GET; binary retrieval only of independently manifested existing bytes; collect only an existing pre-seeded search result, once explicitly. No upload, plugin trigger, scheduler submission, search creation, native import/export, or target execution. Backend default initialization itself must be audited for inherited scheduler/plugin activity before authorization.

Proof required: exact runtime identity/store, API socket namespace, child-container mounts/network/devices/capabilities/egress policy, source/image provenance (dependency-layer unknowns explicit), pre-seeded fixture manifest, bounded startup/readiness, CLI+productionstdioMCP evidence and complete owned-container/network/storage teardown with retryable retained cleanup identity. No unrelated caller container is stopped or modified.

Fail closed: absent explicit approval or unenforceable isolation means backend-dependent live checks stay blocked/unverified. Continue frontend-only safe reads and existing controlled provider tests. Do not expose any ambient socket as fallback.

Expected interaction with targets

Read existing fixture data; launch disposable service processes; write private test configuration/storage; contact explicitly selected local services. Backend initialization requests Docker-compatible runtime control. The precise inherited scheduler/plugin authority remains an open admission question. No firmware or extracted program is executed by this proposal.

Options and tradeoffs

Keep frontend-only read acceptance and report backend-dependent operations unavailable, or authorize a disposable VM/separate identity with an enforced runtime/child policy after review. A second Podman store under the same unrestricted user is insufficient isolation proof.

Verification available so far

Observed frontend-only service results are recorded in the branch verification guide. They do not attest backend isolation or a running source revision. No backend/control socket has been enabled for this proposal.

Success criteria and open questions

An explicit maintainer decision must identify the admissible test boundary and its required proofs before implementation. No implicit approval through silence, source profiles, rootless labels, or passing adapter fixtures. Binary reads and one-shot collection keep their existing issue4110 classifications; only suitably pre-seeded data may be used. Otherwise report them unverified.

References

Existing operation scope: https://github.com/morluto/rea/issues/4110
Current blocked-runtime record: https://github.com/morluto/rea/issues/4110#issuecomment-6194300189
Backend source: github.com/fkie-cad/FACT_core@54aed90bac/src
Contribution gate: https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

Originally created by @dandgabr on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4325 ## Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. - [x] I understand that unresolved contribution scope and authority questions block integration. - [x] This discussion contains no credentials, private samples, or sensitive target data. ## Decision needed Should live FACT REST acceptance be allowed to start the pinned backend against an independently isolated disposable runtime API? This is a pending decision, not an approval or a request to expose the user’s runtime socket. ## Context and evidence Existing decision: https://github.com/morluto/rea/issues/4110 defines REST reads and explicit consuming collection, but does not establish an isolated runtime API authority. Its2026-10-15 comment records backend startup blocked by absent Docker socket. This draft does not authorize startup or change settled route classifications. Requested decision: permit only test-infrastructure provisioning of a disposable FACT backend at source54aed90bacb13c484404018101527c72d0bff6c5 with a separately provisioned rootless identity/store/API or disposable VM. No human Podman/Docker socket or user container namespace/store/home is accessible. Source mount is pinned/read-only; database, firmware storage and runtime state are private; service network internal, REA endpoint literal loopback. A store under the same identity alone does not prove inaccessible host paths; require an enforced filesystem/user boundary and child-container restrictions before startup. Acceptance operations: status, statistics, firmware/file lookup, gaps, object detail, seeded dummy result GET; binary retrieval only of independently manifested existing bytes; collect only an existing pre-seeded search result, once explicitly. No upload, plugin trigger, scheduler submission, search creation, native import/export, or target execution. Backend default initialization itself must be audited for inherited scheduler/plugin activity before authorization. Proof required: exact runtime identity/store, API socket namespace, child-container mounts/network/devices/capabilities/egress policy, source/image provenance (dependency-layer unknowns explicit), pre-seeded fixture manifest, bounded startup/readiness, CLI+productionstdioMCP evidence and complete owned-container/network/storage teardown with retryable retained cleanup identity. No unrelated caller container is stopped or modified. Fail closed: absent explicit approval or unenforceable isolation means backend-dependent live checks stay blocked/unverified. Continue frontend-only safe reads and existing controlled provider tests. Do not expose any ambient socket as fallback. ## Expected interaction with targets Read existing fixture data; launch disposable service processes; write private test configuration/storage; contact explicitly selected local services. Backend initialization requests Docker-compatible runtime control. The precise inherited scheduler/plugin authority remains an open admission question. No firmware or extracted program is executed by this proposal. ## Options and tradeoffs Keep frontend-only read acceptance and report backend-dependent operations unavailable, or authorize a disposable VM/separate identity with an enforced runtime/child policy after review. A second Podman store under the same unrestricted user is insufficient isolation proof. ## Verification available so far Observed frontend-only service results are recorded in the branch verification guide. They do not attest backend isolation or a running source revision. No backend/control socket has been enabled for this proposal. ## Success criteria and open questions An explicit maintainer decision must identify the admissible test boundary and its required proofs before implementation. No implicit approval through silence, source profiles, rootless labels, or passing adapter fixtures. Binary reads and one-shot collection keep their existing issue4110 classifications; only suitably pre-seeded data may be used. Otherwise report them unverified. ## References - Existing operation scope: https://github.com/morluto/rea/issues/4110 - Current blocked-runtime record: https://github.com/morluto/rea/issues/4110#issuecomment-6194300189 - Backend source: https://github.com/fkie-cad/FACT_core/tree/54aed90bacb13c484404018101527c72d0bff6c5/src - Contribution gate: https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 16, 2026):

This decision draft reads well: authorizing only a disposable, rootless, boundary-enforced backend and failing closed otherwise is the right posture, and keeping the acceptance surface read-only plus one explicit pre-seeded collect keeps the trust scope narrow. A few suggestions to tighten the authorization contract: (1) make the backend default-initialization audit (inherited scheduler/plugin activity) an explicit gate that must be re-run whenever the pinned revision changes, not just at first authorization; (2) give the teardown a bounded retry window with a hard timeout for the retained cleanup identity, so an interrupted teardown cannot leave an orphan container holding the store; (3) consider recording the exact rootless identity + socket namespace plus the fixture manifest hash in the acceptance evidence so later runs can diff against it cheaply. Happy to help draft that evidence checklist if useful.

@XinwangTao commented on GitHub (Oct 16, 2026): This decision draft reads well: authorizing only a disposable, rootless, boundary-enforced backend and failing closed otherwise is the right posture, and keeping the acceptance surface read-only plus one explicit pre-seeded collect keeps the trust scope narrow. A few suggestions to tighten the authorization contract: (1) make the backend default-initialization audit (inherited scheduler/plugin activity) an explicit gate that must be re-run whenever the pinned revision changes, not just at first authorization; (2) give the teardown a bounded retry window with a hard timeout for the retained cleanup identity, so an interrupted teardown cannot leave an orphan container holding the store; (3) consider recording the exact rootless identity + socket namespace plus the fixture manifest hash in the acceptance evidence so later runs can diff against it cheaply. Happy to help draft that evidence checklist if useful.

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

@Anvith433 commented on GitHub (Oct 16, 2026):

Hi, I'd like to help work on this issue as a contributor.

I'll start by tracing the existing FACT REST acceptance path and the constraints already recorded in #4110, then document what can be verified safely without starting a backend or exposing any Docker/Podman socket. In particular, I'd check the pinned revision's default initialization for inherited scheduler/plugin activity, and make the evidence requirements explicit for runtime identity, socket namespace, fixture manifest, bounded startup, and teardown.

I understand this is a pending security/design decision, not an authorization to start the service. I'll keep backend-dependent live checks blocked unless maintainers explicitly approve an enforceable isolation boundary. Would you be comfortable assigning this issue to me so I can prepare a focused proposal or safe preparatory contribution?

@Anvith433 commented on GitHub (Oct 16, 2026): Hi, I'd like to help work on this issue as a contributor. I'll start by tracing the existing FACT REST acceptance path and the constraints already recorded in #4110, then document what can be verified safely without starting a backend or exposing any Docker/Podman socket. In particular, I'd check the pinned revision's default initialization for inherited scheduler/plugin activity, and make the evidence requirements explicit for runtime identity, socket namespace, fixture manifest, bounded startup, and teardown. I understand this is a pending security/design decision, not an authorization to start the service. I'll keep backend-dependent live checks blocked unless maintainers explicitly approve an enforceable isolation boundary. Would you be comfortable assigning this issue to me so I can prepare a focused proposal or safe preparatory contribution?

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

@dandgabr commented on GitHub (Oct 16, 2026):

Pinned startup audit and decision requested

The pinned source 54aed90bacb13c484404018101527c72d0bff6c5 requires more than a private rootless API to run backend-dependent REST acceptance:

Backend startup starts scheduler/intercom components; the unpacking scheduler can create extractor workers.
The default extractor launch requests privileged=True and mounts guest /dev read-write. Its recovery path can stop/remove a container matching its image/port, so a runtime store shared with the caller is not an acceptable boundary.
The current proposed acceptance does not call upload, plugin-triggering REST routes, scheduler submission, search creation or target execution. It is limited to named reads and a single explicitly seeded consuming collect, if separately admitted.

Please record which boundary is authorized before any backend startup:

A disposable VM with a separately provisioned runtime/store/API and no host devices, user home, host socket, or external egress, where an explicitly constrained privileged child and synthetic guest /dev are contained; or
A source-pinned reduced backend profile that disables those child effects and is independently shown to provide the requested read workflow.

If neither is acceptable or technically enforceable, please record that backend-dependent live acceptance remains out of scope/unverified. The startup audit must be repeated for every changed source pin/profile. The exact runtime/socket identity, fixture-manifest digest, child policy, bounded readiness, and bounded retryable teardown must be captured. #4110's operation classification does not itself authorize runtime API access; native FACT export is a separate boundary and is not included in this request.

@dandgabr commented on GitHub (Oct 16, 2026): ## Pinned startup audit and decision requested The pinned source `54aed90bacb13c484404018101527c72d0bff6c5` requires more than a private rootless API to run backend-dependent REST acceptance: - Backend startup starts scheduler/intercom components; the unpacking scheduler can create extractor workers. - The default extractor launch requests `privileged=True` and mounts guest `/dev` read-write. Its recovery path can stop/remove a container matching its image/port, so a runtime store shared with the caller is not an acceptable boundary. - The current proposed acceptance does not call upload, plugin-triggering REST routes, scheduler submission, search creation or target execution. It is limited to named reads and a single explicitly seeded consuming collect, if separately admitted. Please record which boundary is authorized before any backend startup: 1. A disposable VM with a separately provisioned runtime/store/API and no host devices, user home, host socket, or external egress, where an explicitly constrained privileged child and synthetic guest `/dev` are contained; or 2. A source-pinned reduced backend profile that disables those child effects and is independently shown to provide the requested read workflow. If neither is acceptable or technically enforceable, please record that backend-dependent live acceptance remains out of scope/unverified. The startup audit must be repeated for every changed source pin/profile. The exact runtime/socket identity, fixture-manifest digest, child policy, bounded readiness, and bounded retryable teardown must be captured. #4110's operation classification does not itself authorize runtime API access; native FACT export is a separate boundary and is not included in this request.

bsakaguchi referenced this issue

2026-10-31 00:54:56 +00:00

[PR #1721] [MERGED] perf(evidence): reuse authenticated file snapshots during session import #4776

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1718

No description provided.

Rows
Columns