cap-add's ALL expansion was a no-op: build_capabilities double-prefixed
cap names (format!("CAP_{name}") over capability_names(), which already
returns "CAP_*"), so every Capability::from_str("CAP_CAP_*") errored and
the container silently kept only the 14-cap default set — missing
SYS_ADMIN/NET_ADMIN that privileged workloads need. Replace the broken
loop with all_capabilities() enumerating all 41 OCI capabilities.

Privileged containers (cap-add ALL/SYS_ADMIN) also need a writable
/proc/sys: dockerd writes net.ipv4.ip_forward to bring up its bridge.
LinuxBuilder otherwise defaults readonlyPaths/maskedPaths to the OCI
lists, which remount /proc/sys read-only — override them with empty sets
when privileged (matching `docker --privileged`). Non-privileged boxes
keep the protective defaults.

Together these let `boxlite run --kernel net --cap-add ALL docker:dind`
start dockerd end-to-end: Daemon initialized, API listening on
/var/run/docker.sock, `docker version` client+server, overlayfs storage,
cgroup v2. Adds guest unit tests for both (all_capabilities superset,
ALL effective set includes SYS_ADMIN/NET_ADMIN, privileged spec clears
readonly/masked paths while non-privileged keeps /proc/sys read-only).

Also rustfmt the kernel-net build.rs constants/Fetcher calls, committed
unformatted in the kernel-selection commit, so the branch passes fmt.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three integration tests on alpine, asserting on `CapEff:` from
/proc/self/status inside the container — the kernel-visible effective
capability mask, i.e. the receiving end of the chain boxlite-ai#597 plumbs:

  CLI --cap-add → BoxOptions.added_caps → proto added_caps
    → guest build_capabilities → OCI Spec process.capabilities
    → libcontainer → /proc/self/status::CapEff

Existing boxlite-ai#597 tests stopped at the host-side `BoxOptions.added_caps`
value; nothing checked whether anything actually reached the container.
This commit exercises the whole chain at the kernel boundary.

  - default_box_cap_eff_matches_docker_baseline:
      a vanilla `run alpine` must yield CapEff == 0xa80425fb (the
      Docker 14-cap default). Catches a regression that silently
      widens/narrows `default_capabilities()`.

  - cap_add_sys_admin_sets_bit_21_in_cap_eff:
      `--cap-add SYS_ADMIN` must produce default | (1<<21). Asserting
      the exact resulting mask (not just bit-21 set) also catches an
      accidental cap-set *replacement* (default bits drop while only
      SYS_ADMIN remains) and host-side double-add / alias drift
      (extra bits appear).
      ---
      This is the test that caught the per-cap normalisation bug fixed
      in the previous commit. Two-side verified on the rebuilt+
      re-embedded guest: pre-fix, CapEff = 0xa80425fb (no SYS_ADMIN);
      post-fix, CapEff = 0xa82425fb (bit 21 set).

  - cap_add_all_grants_full_cap_eff:
      `--cap-add ALL` must set >=38 of the 41 OCI cap bits. The slack
      (vs "exactly 41") accommodates kernel versions where the OCI
      spec hasn't caught up with a new cap, without giving a
      false-positive on a regression that drops 3+ caps. Pins the
      8f63e3b fix to the `ALL` arm.

Reading CapEff via `awk '/^CapEff:/ {print $2}' /proc/self/status`
needs nothing more than busybox + procfs — alpine:latest ships both.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…TY exec inheritance + parse-time validation)

Inverts the cap baseline and rewires the surface accordingly:

  - default ALL caps on  (was: docker 14)
  - --cap NAME=0   drops one
  - --cap NAME=1   explicit grant (no-op vs default but allowed for audit)
  - --cap ALL=0    drops every cap (zero-cap sandbox)
  - --cap ALL=1    default, no-op
  - CAP_ prefix optional on every name; case-insensitive

The reason for the inversion: in boxlite the trust boundary is the VM
(libkrun), not the container. A docker-style restricted-default added
friction without adding meaningful isolation against the host, because
escaping the container only gets you the guest kernel — which libkrun
contains regardless of what caps the container has.

The previous `--cap-add` surface tried to thread an "additive on top
of 14" model through the same plumbing, which had three layered bugs
the symmetric model makes structurally hard to reintroduce:

  (a) The ALL-expansion arm double-prefixed (CAP_CAP_*), silently
      no-op'ing `--cap-add ALL`. Fixed in 8f63e3b but the bug pattern
      survived.
  (b) The per-cap arm added CAP_ before calling oci-spec 0.6's
      Capability::from_str — which only accepts the bare form
      ("SYS_ADMIN"), not the prefixed one. Every per-cap add silently
      dropped into a warn-and-skip; `--cap-add SYS_ADMIN` never
      reached the container. Fixed in 463064a (this branch).
  (c) Both exec paths (zygote.rs TTY + non-TTY) hardcoded their own
      cap source instead of inheriting the container's. TTY exec
      passed `build_capabilities(&[])`; non-TTY passed
      `capability_names()` (the docker 14 list verbatim). So even
      a correctly-added SYS_ADMIN on the container's init was
      silently dropped on every `boxlite exec` — the operator saw
      the cap on the init process, then lost it on every subsequent
      shell into the box.

All three are fixed structurally by the new model:

  - There is exactly one cap source: `resolve_cap_set(cap_overrides)`,
    starting from `all_capabilities()` and applying entries in order.
    No additive vs. replace ambiguity; no "first match" vs "ALL only".

  - Per-cap normalisation is one line: `strip_prefix("CAP_")`. Both
    `--cap SYS_ADMIN=0` and `--cap CAP_SYS_ADMIN=0` produce the same
    override before `Capability::from_str` is called.

  - Unknown cap names error at CLI parse (oci-spec's from_str is the
    authoritative dictionary, pulled in as a build-only dep on
    boxlite-cli). A typo like `SYS-ADMIN=0` fails `boxlite run`
    before the box is created — no silent guest-side warn.

  - BuildSpec carries the container's `cap_overrides` through the
    zygote IPC. Both TTY (build_tty_exec_process) and non-TTY
    (`with_capabilities(cap_override_libcontainer_names(...))`) exec
    paths replay the same overrides as init.

Plumbing surface:

  schema/proto       BoxOptions { cap_overrides: Vec<CapOverride> }
                     and `repeated CapOverride cap_overrides = 6` in
                     ContainerInitRequest.  CapOverride is a (name,
                     enabled) pair with serde and prost derives.

  host bridge        portal/interfaces/container.rs maps host-side
                     CapOverride → proto.

  guest-local mirror container/capabilities.rs defines a serde-
                     deriving CapOverride that the zygote IPC carries
                     in BuildSpec. From<boxlite_shared::CapOverride>
                     bridges proto → local at the gRPC boundary in
                     service/container.rs.

  Container         stashes cap_overrides at start; ContainerCommand
                     reads them via self.cap_overrides on cmd(); each
                     BuildSpec replay copies them in.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Six integration tests on alpine, each asserting on `CapEff:` from
/proc/self/status inside the container — the kernel-visible effective
capability mask, i.e. the receiving end of the chain the previous
commit plumbs:

  CLI --cap NAME=0|1 → BoxOptions.cap_overrides → proto cap_overrides
    → guest build_capabilities → OCI Spec process.capabilities
    → libcontainer → /proc/self/status::CapEff

Asserting at the kernel end catches a regression anywhere in that
chain, including ones that pass the parse-layer unit tests.

  - default_box_cap_eff_is_essentially_all:
      empty cap_overrides yields >=38 of 41 OCI cap bits and
      explicitly includes CAP_SYS_ADMIN (bit 21). The diagnostic
      message names the most likely regression source (a sneak
      reappearance of `default_capabilities()` in the cap baseline).

  - cap_drop_sys_admin_clears_bit_21_only:
      `--cap SYS_ADMIN=0` produces `baseline & !(1<<21)`. The exact
      equality catches over-broad drops (more than one bit removed)
      AND silent grants (bit 21 still set) in the same pass; either
      direction of regression flips the test red.

  - cap_all_zero_clears_every_bit:
      `--cap ALL=0` empties CapEff entirely — the zero-cap sandbox
      use case (e.g. CTF payloads that shouldn't even bind a low
      port).

  - cap_all_zero_then_sys_admin_one_leaves_just_bit_21:
      Pins the "later overrides earlier" semantics. Without this,
      "minimum permission + one specific cap" isn't expressible.

  - exec_inherits_container_cap_drops:
      Pins that `boxlite exec` reads the *container's* cap_overrides
      rather than silently falling back to a hardcoded default. This
      is what catches the inverted exec leak under the default-ALL
      model — pre-fix, `--cap SYS_ADMIN=0` on the container left
      SYS_ADMIN granted on every exec'd process. Two-side verified:
      reverting BuildSpec.cap_overrides to `vec![]` re-produces
      CapEff = 0x000001ffffffffff (full ALL, including bit 21) on
      the exec'd process, which the test correctly catches.

  - cap_unknown_name_rejected_at_cli_parse:
      A typo like `SYS-ADMIN=0` (dash) must fail at `boxlite run`
      parse, not silently no-op in the guest log. The CLI parse
      layer is the first opportunity to reject — failing here also
      means the box never starts, which is the right behaviour
      (better to refuse than to produce an unintendedly-permissive
      container).

Reading CapEff via `awk '/^CapEff:/ {print $2}' /proc/self/status`
needs nothing more than busybox + procfs — alpine:latest ships both.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…-name later-overrides-earlier

Two unit tests on spec.rs alongside the existing five
`build_capabilities_*` cases:

  - tty_exec_process_honours_cap_overrides:
      `boxlite exec -t` goes through `build_tty_exec_process` instead
      of the non-TTY `with_capabilities(...)` builder. The kernel-level
      integration test `cap::exec_inherits_container_cap_drops` only
      covers the non-TTY path (assert_cmd has no real PTY parent), so
      the TTY hop was previously only pinned by inspection. This test
      calls `build_tty_exec_process(..., &[SYS_ADMIN=0])` and asserts
      the resulting OCI Process spec's effective set both drops
      SysAdmin AND preserves NetAdmin (= not collapsed back to a
      14-cap docker baseline). Two-side verified: hardcoding
      `build_capabilities(&[])` re-introduces the pre-fix state and
      reproduces the 41-cap-with-SysAdmin failure verbatim.

  - build_capabilities_same_name_later_overrides_earlier:
      Pins the "later overrides earlier" ordering rule for entries
      hitting the same cap name. `SYS_ADMIN=0` then `SYS_ADMIN=1`
      must end up granted; the reverse must end up dropped. The
      existing `all_zero_then_sys_admin_one` test pinned the rule
      for `ALL=0 → NAME=1` but not for repeated same-name entries,
      which a future caller (REST config layering, env-var append)
      will produce.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…rver + serde)

boxlite-ai#597's `--cap NAME=0|1` flag worked end-to-end through the local CLI
path, but the REST path silently dropped every override:

  - boxlite/src/rest/types.rs::CreateBoxRequest (the *client-side*
    wire form sent by `RestRuntime::create`) had no `cap_overrides`
    field, so `from_options(&BoxOptions)` discarded
    `BoxOptions.cap_overrides` before serialization.

  - cli/src/commands/serve/types.rs::CreateBoxRequest (the
    *server-side* form deserialized by `POST /v1/boxes`) also had
    no `cap_overrides` field, AND used `#[serde(deny_unknown_fields)]`
    — so even if a hand-rolled client had POSTed the right JSON, the
    server would have rejected it with a 4xx.

  - serve::build_box_options used `..Default::default()` to fill in
    everything beyond the explicit fields, so even with the previous
    two fixes the server would have stopped at an empty list.

Net effect: any client routing through REST — including the Python,
Node, Go SDKs once they expose `--cap` — saw the new flag in the CLI
but got the default-ALL baseline regardless of what they asked for.

Fix:

  - Add `cap_overrides: Option<Vec<CreateBoxCapOverride>>` to both
    structs.  The wire type is a thin name/enabled pair owned by the
    rest module so the field can keep `skip_serializing_if = "Option::
    is_none"` for backward compatibility (existing clients that never
    set `--cap` don't change their POST body shape).

  - Conversions:
      • `BoxOptions → CreateBoxRequest` (rest::types) populates the
        field from `options.cap_overrides`, None when empty.
      • `CreateBoxRequest → BoxOptions` (serve::build_box_options)
        unwraps Option to `vec![]` when absent (= default-ALL) and
        maps each entry into `boxlite::CapOverride`.

  - Bidirectional `From` impls on `CreateBoxCapOverride` ↔
    `runtime::options::CapOverride` so the converter sites stay
    one-liners.

Pinned by four new unit tests:

  - test_create_box_request_carries_cap_overrides_on_the_wire
  - test_create_box_request_omits_cap_overrides_when_empty
  - build_box_options_threads_cap_overrides_from_rest_body
  - build_box_options_no_cap_overrides_defaults_to_empty

The first two pin the client side (BoxOptions → JSON), the last two
the server side (JSON → BoxOptions), and the empty-case tests pin
the backward-compat contract for pre-existing clients.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CapEff-bitmask asserts cover the kernel's *view* of the cap set, but
the load-bearing question for an operator is whether the kernel
actually *enforces* the cap. This test threads `mount(2)` through
both ends of the contract:

  - Default-ALL box: `mount -t tmpfs tmpfs /tmp/mnt` must succeed
    (with SYS_ADMIN granted, the cap check passes and the mount
    landing site is unconstrained for an empty dir under /tmp).

  - `--cap SYS_ADMIN=0` box: the same call must fail with EPERM.
    BusyBox `mount` translates EPERM to "permission denied (are
    you root?)"; either the textual cue or `Operation not permitted`
    counts. The exit-code AND text conjunction catches a regression
    that produces the right exit through an unrelated failure
    (e.g. a broken mount binary).

This closes the gap between "the cap is in CapEff" (existing tests)
and "the cap actually gates a SYS_ADMIN-bound syscall." A regression
that, say, populates the bounding set but not the effective set
would pass the CapEff tests and silently fail enforcement; this test
keeps it red.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>