mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-09 10:21:03 +00:00
Anso
b740dd1078
* feat(resources): protect Sencho's own image, network, volumes from deletion Adds SelfIdentityService that reads HOSTNAME at startup and inspects the running Sencho container via Dockerode to record its image ID, attached networks, named volumes, and container ID. The classification API marks these with isSencho:true, destructive delete routes return 423 Locked when the target matches self, the orphan-containers API filters the Sencho container out so it cannot be selected and purged from the Unmanaged tab, and the managed-prune path adds an explicit self filter for defense-in-depth on top of Docker's in-use semantics. The Resources view renders a Sencho pill alongside the managed badge on matching rows and disables the trash control with a hover tooltip. When Sencho runs outside Docker (dev mode), inspect returns 404, the service stays empty, and every isOwn* returns false so today's behaviour is preserved. * fix(resources): handle sha256-prefixed image IDs and custom hostnames Addresses independent-review findings on PR #1149: - Strip sha256: prefix in POST /api/system/images/delete before validating the ID, matching the inspect route's handling. Without this, /system/images responses round-trip through the UI as sha256:<hex> and got 400 Invalid image ID format before rejectIfSelf could run. - Add /proc/self/cgroup fallback to SelfIdentityService so custom --hostname, Compose hostname:, or --uts=host setups still self-identify. HOSTNAME inspect runs first; on 404 the service parses the cgroup file for a 64-hex container ID (cgroupv1 docker, cgroupv2 docker, podman libpod formats all covered) and retries inspect with that ID. - Restrict prefix matching in isOwnNetwork / matchesId to hex-shaped candidates (12 to 64 hex chars), so a non-Sencho network whose name happens to start with a hex prefix of Sencho's network ID is no longer flagged as self. - Trim the resources.mdx Note to customer-visible behaviour without enumerating every tab. - New tests: prefixed-image-ID 200 path, three cgroup file format parses (v1, v2, podman) plus the no-match and missing-file cases, HOSTNAME-404-then-cgroup-success fallback path, name-collision regression for the hex-only prefix rule, and an empty-cache no-regression check. Test hygiene: mockReset on the inspect stub and restoreAllMocks in afterEach so spies do not leak across tests. * chore(security): VEX not_affected for CVE-2026-46680 (containerd in docker-compose) Trivy now flags CVE-2026-46680 HIGH on usr/local/lib/docker/cli-plugins/docker-compose, which statically embeds github.com/containerd/containerd/v2 v2.2.3 (compose v5.1.3's resolved module graph). The CVE is a runtime-executor flaw: containerd's runc invocation can be tricked into running a Kubernetes pod marked runAsNonRoot as root via crafted user ID handling. The vulnerable code path is reached only by containerd-shim executing a container with a populated OCI runtime spec on the daemon side. docker-compose vendors the containerd Go module purely as a client (gRPC stubs, API types, shared utilities); it never executes containers and never enforces runAsNonRoot. Sencho's compose usage (up / down / ps against user-authored files) cannot construct a Kubernetes pod security context. The vulnerable path is unreachable. Adds a not_affected entry to security/vex/sencho.openvex.json with justification vulnerable_code_not_in_execute_path, bumps version 5 to 6, and updates last_updated to 2026-05-22 per Directive 23.
72 lines
5.6 KiB
JSON
72 lines
5.6 KiB
JSON
{
|
|
"@context": "https://openvex.dev/ns/v0.2.0",
|
|
"@id": "https://github.com/studio-saelix/sencho/security/vex/sencho.openvex.json",
|
|
"author": "Studio Saelix",
|
|
"role": "Vendor",
|
|
"timestamp": "2026-05-18T00:00:00Z",
|
|
"last_updated": "2026-05-22T00:00:00Z",
|
|
"version": 6,
|
|
"statements": [
|
|
{
|
|
"vulnerability": {
|
|
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-34040",
|
|
"name": "CVE-2026-34040",
|
|
"description": "Moby/Docker daemon authorization bypass"
|
|
},
|
|
"products": [
|
|
{
|
|
"@id": "pkg:golang/github.com/docker/docker@v28.5.2+incompatible"
|
|
}
|
|
],
|
|
"status": "not_affected",
|
|
"justification": "vulnerable_code_not_in_execute_path",
|
|
"impact_statement": "The authorization bypass affects Docker Engine's daemon-side plugin authorization hook on oversized request bodies. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never acts as a daemon and never runs authorization hooks. Sencho invokes compose only for up/down/ps operations against local user-authored compose files. The daemon auth code path is not reachable. The advisory's 'fixed in 29.3.1' refers to Docker Engine the daemon product. The Go library containing the fix is github.com/moby/moby/v2 (a new module path adopted on the docker-29.x branch), not github.com/docker/docker. Until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version."
|
|
},
|
|
{
|
|
"vulnerability": {
|
|
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-41567",
|
|
"name": "CVE-2026-41567",
|
|
"description": "Docker: PUT /containers/{id}/archive executes container binary on the host"
|
|
},
|
|
"products": [
|
|
{
|
|
"@id": "pkg:golang/github.com/docker/docker@v28.5.2+incompatible"
|
|
}
|
|
],
|
|
"status": "not_affected",
|
|
"justification": "vulnerable_code_not_in_execute_path",
|
|
"impact_statement": "The vulnerable code is the Docker Engine daemon-side handler for the PUT /containers/{id}/archive endpoint, which under certain conditions resolves the archive target by executing a binary from inside the container on the host. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never serves daemon HTTP routes. Sencho invokes compose only for up/down/ps operations against local user-authored compose files and never calls the /archive route in either direction. The daemon-side archive handler is not reachable. The fix lives on the github.com/moby/moby/v2 module path; until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version of the affected library that compose can reference."
|
|
},
|
|
{
|
|
"vulnerability": {
|
|
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-42306",
|
|
"name": "CVE-2026-42306",
|
|
"description": "Docker: Race condition in docker cp allows bind mount redirection to host"
|
|
},
|
|
"products": [
|
|
{
|
|
"@id": "pkg:golang/github.com/docker/docker@v28.5.2+incompatible"
|
|
}
|
|
],
|
|
"status": "not_affected",
|
|
"justification": "vulnerable_code_not_in_execute_path",
|
|
"impact_statement": "The race condition is in the Docker Engine daemon-side bind-mount resolution path that backs `docker cp`, where a concurrent rename can redirect a copy operation onto a host path. docker-compose v5.1.3 statically bundles docker/docker v28.5.2+incompatible as a client-side library for API types and codecs; it never serves the daemon-side cp endpoint and never resolves bind mounts on the host. Sencho invokes compose only for up/down/ps operations against local user-authored compose files and does not invoke `docker cp` through compose. The vulnerable daemon-side code path is not reachable. The fix lives on the github.com/moby/moby/v2 module path; until upstream compose migrates to the v2 import path, v28.5.2+incompatible is the only Go-module-resolvable version of the affected library that compose can reference."
|
|
},
|
|
{
|
|
"vulnerability": {
|
|
"@id": "https://www.cve.org/CVERecord?id=CVE-2026-46680",
|
|
"name": "CVE-2026-46680",
|
|
"description": "containerd user ID handling bypass allows runAsNonRoot evasion"
|
|
},
|
|
"products": [
|
|
{
|
|
"@id": "pkg:golang/github.com/containerd/containerd/v2@v2.2.3"
|
|
}
|
|
],
|
|
"status": "not_affected",
|
|
"justification": "vulnerable_code_not_in_execute_path",
|
|
"impact_statement": "The vulnerability is in containerd's runtime executor: when starting a container whose OCI spec carries a Kubernetes `runAsNonRoot: true` security context, a crafted user ID handling sequence lets the process run as root despite the enforcement check. The vulnerable code path is reached only by containerd-shim invoking runc with a populated runtime spec, i.e., daemon-side execution by the containerd runtime itself. docker-compose v5.1.3 statically bundles `github.com/containerd/containerd/v2 v2.2.3` as a client-side library for gRPC types, API stubs, and shared utilities used to talk to a containerd daemon; it does not execute containers and does not enforce `runAsNonRoot`. Sencho invokes compose only for up/down/ps operations against user-authored compose files, which do not carry Kubernetes pod security contexts. The runtime-executor code path is not reachable. Upstream compose will pick up the fixed containerd (v2.2.4 / v2.3.1) on a future tag; until then v2.2.3 is the resolved version in compose v5.1.3's module graph."
|
|
}
|
|
]
|
|
}
|