Idea. For users wanting in-guest least-privilege on top of coop's VM boundary, support and document running an in-guest sandboxing layer (Landlock-based filesystem restrictions + seccomp user-notification syscall mediation) inside a coop guest. This composes with — rather than replaces — the disposable VM boundary, and is cheaper than reimplementing a filesystem/syscall sandbox from scratch (much of which is redundant with the disposable VM anyway).
Concrete blockers to resolve first:
- Passwordless sudo. A
no_new_privs-based sandbox disables passwordless sudo inside the guest — needs reconciling with coop's default guest UX.
- Guest kernel config. The guest kernel must ship
CONFIG_SECURITY_LANDLOCK + seccomp user-notification; coop currently treats its Firecracker CI kernel as fixed, so this needs a validated kernel config.
- Docker socket. The root Docker socket in the guest is a straight bypass of any in-guest boundary — must be blocked or brokered.
Deliverable. A docs page (could live alongside the design/security docs) + a validated guest kernel config + an optional profile that installs the sandbox layer and its baseline policies.
Open question — how does an in-guest sandbox relate to coop? Undecided: design reference, optional in-guest layer, or a coop backend? This issue assumes optional in-guest composition; revisit the framing if that changes.
Refs. #2 (egress — an in-guest layer could provide the L7 layer) and #411 (credential non-exposure).
Idea. For users wanting in-guest least-privilege on top of coop's VM boundary, support and document running an in-guest sandboxing layer (Landlock-based filesystem restrictions + seccomp user-notification syscall mediation) inside a coop guest. This composes with — rather than replaces — the disposable VM boundary, and is cheaper than reimplementing a filesystem/syscall sandbox from scratch (much of which is redundant with the disposable VM anyway).
Concrete blockers to resolve first:
no_new_privs-based sandbox disables passwordless sudo inside the guest — needs reconciling with coop's default guest UX.CONFIG_SECURITY_LANDLOCK+ seccomp user-notification; coop currently treats its Firecracker CI kernel as fixed, so this needs a validated kernel config.Deliverable. A docs page (could live alongside the design/security docs) + a validated guest kernel config + an optional profile that installs the sandbox layer and its baseline policies.
Open question — how does an in-guest sandbox relate to coop? Undecided: design reference, optional in-guest layer, or a coop backend? This issue assumes optional in-guest composition; revisit the framing if that changes.
Refs. #2 (egress — an in-guest layer could provide the L7 layer) and #411 (credential non-exposure).