Document standalone MXC executable placement and condition system-drive ACL preparation on the AppContainer + DACL tier and probe recommendation. Explain the persistent metadata-only grant and link upstream verification and rollback guidance.
NVBug: 6842834
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
Signed-off-by: Shailendra Singh <shailendras@nvidia.com>
* fix(core): enforce owner-only Windows ACLs on sensitive files and dirs
set_dir_owner_only/set_file_owner_only were unconditional no-ops on
Windows, so the CLI's mTLS client private key, OIDC/edge tokens, cached
SSH keys, and the gateway's key-encryption key relied entirely on
inherited NTFS ACLs with no OpenShell-applied restriction. Apply an
owner-only DACL via SetEntriesInAclW/SetNamedSecurityInfoW with
PROTECTED_DACL_SECURITY_INFORMATION to strip inherited ACEs, matching
the 0700/0600 guarantee already provided on Unix. is_file_permissions_too_open
now also works on Windows instead of being Unix-only, closing the
detection gap alongside the prevention gap.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit 71560e947f85819efbcddf70ddda94befab62b0b)
* fix(core): treat a NULL DACL as too open in is_file_permissions_too_open
has_foreign_trustee conflated a NULL DACL with an unreadable/invalid
ACL and returned Some(false) (not too open) for both. Per the Win32
contract, a NULL DACL means the object grants full access to everyone
-- the most permissive state possible -- so it must be flagged as too
open. Split the null and invalid-ACL branches: null now returns
Some(true), invalid ACL keeps the existing unreadable-ACL fallback
(None, which the caller maps to false via unwrap_or). Adds a
regression test that constructs a real NULL DACL via a
SetNamedSecurityInfoW helper confined to the windows_acl module,
consistent with the existing unsafe-FFI confinement in that module.
Found by CodeRabbit review on MR !113.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit 46e635a4ef1d6937cdb088f46aa85baee3d6ad28)
* fix(core): close three false-negative gaps in the Windows ACL audit
restrict_to_current_user() updated only the DACL, leaving a foreign
owner's implicit WRITE_DAC right intact -- they could later replace
the DACL we just set. Query OWNER_SECURITY_INFORMATION and take
ownership in the same SetNamedSecurityInfoW call; if the caller can't
(a genuinely foreign-owned object), the call now fails instead of
silently leaving the object insecure.
is_file_permissions_too_open() mapped every Win32 inspection failure
(missing READ_CONTROL, an invalid ACL, a token-query failure) to
"not too open" via unwrap_or(false). Fail closed instead: an
inspection failure is a security false-negative risk, not a green
light.
has_foreign_trustee()'s ACE loop only recognized plain
ACCESS_ALLOWED_ACE_TYPE and treated every other type as non-granting.
Windows also defines access-allowed object, callback, and
callback-object ACE variants that can grant rights to a foreign
trustee; this audit doesn't parse their wider layouts, so their mere
presence is now conservatively flagged as too open instead of
silently skipped.
Also updates architecture/gateway.md, which still described the
SQLite file-tightening behavior only in terms of Unix mode 0o600, to
distinguish it from the owner-only DACL behavior on Windows.
Addresses review comments on PR #3495.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(core): conditional owner claim and audit owner in Windows ACL helpers
restrict_to_current_user: query the current owner before calling
SetNamedSecurityInfoW. Include OWNER_SECURITY_INFORMATION only when the
path has a foreign owner -- requesting it unconditionally fails with
ACCESS_DENIED (0x80070005) on standard credentials even when the current
user is already the owner, because WRITE_OWNER is not implied by object
ownership. A foreign-owned path still triggers an ownership claim and
fails hard if the claim is denied, preserving the security contract.
has_foreign_trustee: request OWNER_SECURITY_INFORMATION alongside
DACL_SECURITY_INFORMATION and reject paths with a foreign owner
immediately, before inspecting the DACL. A foreign owner has implicit
WRITE_DAC rights and can replace any DACL we set, so a clean DACL is not
sufficient evidence of safety on a foreign-owned object.
architecture/gateway.md: clarify that the Windows path-hardening behavior
sets mode 0o600 on Unix and applies a protected owner-only DACL on
Windows, with conditional ownership claim and fail-hard semantics for
foreign-owned objects.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(ocsf): attribute MXC proxy events to sandboxes
NVBug 6783086
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
* fix(network): scope Windows egress by socket owner
Resolve each accepted Windows proxy connection to its unique owning PID and executable before evaluating binary-scoped network policy. Fail closed when ownership or process identity cannot be established, and cover allowed and undeclared child processes with a real MXC regression.
* fix(network): preserve sandbox context with socket owners
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
(cherry picked from commit 32ea316deb6c83c157fdf2de4a2cdc3a7d2da1e3)
* fix(network): harden Windows process identity
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
---------
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
* fix(mxc): honor the generic sandbox create -- <COMMAND> syntax
sandbox_config only ever read the command from the MXC-specific
driver_config (--driver-config-json), never DriverSandboxSpec.command
-- the portable field the CLI's documented, driver-agnostic
`sandbox create -- <COMMAND>` syntax actually populates, and the same
field every other compute driver honors. A caller following that
syntax got "driver_config.command must contain a non-empty
executable", a message that reads as if no command was supplied at
all.
Add spec.command as a fallback source when no driver_config is
present, and reword the empty-command error to name both ways to
supply one.
NVBug 6782884
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* docs(mxc): document generic sandbox commands
Signed-off-by: Shailendra Singh <shailendras@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
Signed-off-by: Shailendra Singh <shailendras@nvidia.com>
Co-authored-by: Shailendra Singh <shailendras@nvidia.com>
* fix(network): normalize Windows policy binary paths
Match Windows executable identities using a stable case-insensitive, separator-normalized representation across policy data, L4 input, and L7 relay evaluation. Preserve exact matching on other platforms and keep the original path for hashing and filesystem access.
NVBug 6782969
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
* fix(network): harden Windows binary matching
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
* fix(ci): scope Windows relay test imports
* fix(network): harden Windows binary path matching
---------
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
* fix(server): keep Error-phase sandbox records through the prune sweep
The periodic store-vs-backend reconciliation sweep deleted any
persisted sandbox not present in the driver's live backend snapshot,
except for Completed and failed-main-process phases. A driver whose
registry is in-process-only and never rehydrates after a restart (no
persistence of its own) reports every previously-known sandbox as
missing on the very first sweep after startup -- including ones
already correctly, terminally marked Error by earlier crash detection
-- so the sweep silently deleted them shortly after gateway restart,
racing any client (GetSandbox/ListSandboxes/DeleteSandbox) working
with the same sandbox in that window.
Treat Error the same as the existing Completed exemption: it is
already a settled, informational terminal state with no live compute
resource to reclaim, so keep the durable record instead of deleting
it.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit 721a1659a822a72e76e3c0dffc6847f17129a3fc)
* fix(server): narrow the prune sweep's Error-phase exemption
The blanket phase == SandboxPhase::Error exemption changed established
missing-backend cleanup for every compute driver, not only the MXC
restart race the PR intended to fix. It also matched
BackendResourceMissing (set by gateway-startup recovery when a
previously-known sandbox's backend resource is already gone),
StartFailed (startup recovery's driver-error case), and
ComputeResourceMissing (this same sweep's own first-pass Error
transition for a Stopping/Stopped/Starting sandbox). All three mark
exactly the orphaned resources this sweep exists to reclaim across
Docker, Podman, VM, Kubernetes, and extension drivers -- exempting
them left orphaned names and gateway-owned records in place
indefinitely and skipped the idempotent driver cleanup for
volumes/secrets until a user explicitly deleted the sandbox.
Add is_missing_compute_resource_reason to inspect the sandbox's Ready
condition and narrow the exemption to a settled Error record only: one
whose reason isn't one of those three. A crashed main process or any
other non-resource failure keeps the exemption (no live resource ever
expected again); a resource-missing reason keeps flowing through the
normal delete-and-cleanup path exactly as before this PR.
Adds regression coverage for BackendResourceMissing and
ComputeResourceMissing confirming they are still pruned with driver
cleanup invoked, and documents the settled-vs-missing-resource
retention distinction in architecture/compute-runtimes.md.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* feat(mxc): warn when the ETW consumer receives zero provider events
EnableTraceEx2 succeeding only proves the request to enable the
Sandboxing provider succeeded, not that the provider exists on this
host/build or will ever fire. A provider-identity mismatch or a
non-firing provider left the ETW->OCSF audit trail silently empty
across real, successful sandbox lifecycles, with no error, warning,
or diagnostic anywhere.
Track raw provider-matched events received per session and add a
zero-events watchdog on the consumer thread: once real sandbox
activity has happened (register_launch called at least once) and a
grace period elapses with zero events matched, log a warning and
emit a Detection Finding [2004] naming the gap. Gated on actual
activity (not just session uptime) so an idle gateway with
etw_audit=true and no sandboxes created never warns.
Also exposes EtwSession::events_received() alongside the existing
is_capture_alive(), so a status/diagnostics surface can query capture
health directly, not just infer it from tracing output.
The watchdog's decision logic is extracted into a pure function
(should_warn_zero_events) so it's unit-testable without a real ETW
session or elevation.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit 4fcfa716a808eaa91c6476e9c69366f91702b1fa)
* fix(mxc): repair build/lint breaks left by the zero-events watchdog commit
warn_zero_events_received() referenced a nonexistent SESSION_NAME
constant (only SESSION_NAME_PREFIX exists), so the crate failed to
compile. Separately, the consumer thread's decode-or-log match on
Option<DecodedEtwEvent> tripped clippy::single_match_else under -D
warnings. Neither issue is specific to a platform or toolchain
version -- both reproduce on a clean checkout of this branch's tip.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(mxc): attribute ETW Sandboxing-provider events via identity/CV, not PID
The Sandboxing provider's events are logged under two PIDs that are
never the driver's own wxc-exec PID: a short-lived launcher PID
(wxc-exec.exe exits within seconds even while the sandboxed workload
keeps running) and a shared, constant PID hosted by a system-wide OS
broker service across unrelated sandboxes. Anchoring attribution on
`register_launch`'s wxc_pid therefore left every event unattributable,
so the OCSF audit trail stayed empty despite the provider firing
correctly (confirmed against a raw logman/tracerpt capture running
alongside this consumer).
wxc-exec never reports its OS-generated `identity`/`__TlgCV__` back to
the driver, so there is nothing to pre-seed `by_identity` with at
registration time the way `by_pid` is pre-seeded. Track launches still
awaiting their first identity/CV in a `pending_launches` queue instead,
and bind opportunistically in `resolve()`: when an event carries a
never-seen identity/CV and has no `by_pid` registration at all (the
real-world shape of these events) and exactly one launch is pending,
it can only be that launch's burst. Zero or multiple pending launches
stay ambiguous and fall through to the existing unresolved-event
buffer/TTL path rather than guess -- misattributing an audit event to
the wrong sandbox_id is worse than dropping it. A PID registration
that does exist (even generation-mismatched) is treated as positive
evidence of an existing PID-reuse race and takes precedence over the
opportunistic path, preserving the existing generation-key guarantees.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(mxc): surface dropped-unattributed ETW events above debug level
An event that ages out of the unresolved-event buffer unattributed is
a permanent audit-trail gap: the OS action it represents will never
appear in the OCSF log, and nothing retries it afterward. That was
only visible at --log-level debug, so an operator running with the
default level would never see it. Promote it to warn, matching the
severity already used for the zero-events watchdog's own gap warning.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(mxc): keep ETW attribution fail-closed, rate-limit drop warnings
The prior opportunistic "single pending launch" fallback attributed
any fresh identity/CV from an unregistered or system-broker PID to
the sole pending OpenShell launch. Queue cardinality is not
attribution evidence: unrelated, non-OpenShell AppContainer or UAC
activity shares this same OS Sandboxing provider, so an event
arriving in the five-second window could cross-link an unrelated
identity and emit subsequent events under the wrong sandbox_id,
corrupting the audit trail. Revert it -- attribution requires the
driver-owned wxc-exec PID and its kernel process start key to both
match, exactly as before. Records without that generation-backed
evidence remain unattributed rather than guessed.
The dropped-unattributed warning also moved from one line per record
to a rate-limited, aggregated warning: unattributed drops are
expected, ordinary system-wide activity, not a rare condition, so
warning per record could flood operator logs during a burst of
unrelated AppContainer/UAC activity. UnattributedDropReporter mirrors
the existing OverloadReporter pattern -- warn immediately on the
first drop, then coalesce to one warning with a running count every
30 seconds while drops continue.
Updates the MXC observability documentation to match: the
unattributed-record sentence now explains why fail-closed is
deliberate, documents the coalesced warning cadence, and documents
the mxc-etw-zero-events OCSF Detection Finding [2004], which was not
mentioned anywhere before.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(mxc): reject a non-absolute wxc_exec_path at gateway startup
wxc_exec_path is the binary that builds every sandbox, but nothing
validated it before spawning: a relative value (including the shipped
default, a bare "wxc-exec.exe") let PATH-lookup or working-directory-
relative resolution execute a decoy binary with the gateway's identity
instead of the approved wxc-exec, turning the containment mechanism
itself into an arbitrary-code-execution primitive.
Add MxcComputeConfig::validate_configuration, wired into the existing
(previously no-op) compute-driver config preflight, rejecting an
empty or non-absolute wxc_exec_path with a clear diagnostic. Change
the default from the relative "wxc-exec.exe" to an empty string so
the field must be explicitly configured -- no usable-but-insecure
fallback survives. Update the architecture doc's stale "else PATH"
discovery claim to match.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit d4192a0072f8f0ca0a4035f10cae07889c2b578f)
* test(mxc): cover wxc_exec_path enforcement at the gateway boundary
MxcComputeConfig::validate_configuration already had unit coverage,
but that only proves the validation function itself is correct -- it
says nothing about whether MxcFactory::validate_config (src/lib.rs)
still calls it. Before this fix, that factory method discarded the
parsed config entirely, so a regression back to that no-op shape would
leave every unit test passing while a relative wxc_exec_path again
reached gateway startup.
Add an integration test that spawns the actual compiled
openshell-gateway binary through its config preflight subcommand,
exercising the real chain: CLI parsing, TOML loading, driver
selection, MxcFactory::validate_config, and
MxcComputeConfig::validate_configuration. Assertions check only
pass/fail, not message content: run_effective_config_preflight
replaces any validation failure with a generic message whenever a
config file is used, to keep file-sourced values out of preflight
diagnostics -- pre-existing, deliberate, and covered by its own tests.
Also document the new required-and-absolute wxc_exec_path constraint
in the gateway config reference and the driver README, which
previously only showed example values without stating the
requirement.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
* fix(mxc): stage egress-proxy CA files regardless of env tier
stage_tls_ca_files was only invoked when pc_minimal_env was set, but a
curated ProcessContainer can't read the host proxy's private temp
folder under any env tier. With the default pc_minimal_env=false, the
CA env vars pointed at a path the sandboxed process couldn't read at
all, breaking TLS validation for allow-listed HTTPS requests through
the egress proxy. Extract the staging decision into
resolve_agent_proxy_ca_paths, which takes no env-tier argument, so the
gap can't silently regress; existing tests never exercised this path
since mocked invokers skip host-proxy startup entirely.
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
(cherry picked from commit d0346af96aef9a93aca26a7e1825d8678a25567d)
* fix(mxc): complete proxy CA staging isolation (#3535)
* test(mxc): provide workload dir for CA staging
Signed-off-by: Prekshi Vyas <prekshivyas@nvidia.com>
* fix(mxc): isolate staged proxy CA files
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
---------
Signed-off-by: Prekshi Vyas <prekshivyas@nvidia.com>
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
---------
Signed-off-by: Prashant Khodade <pkhodade@nvidia.com>
Signed-off-by: Prekshi Vyas <prekshivyas@nvidia.com>
Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>
Co-authored-by: Prekshi Vyas <34834085+prekshivyas@users.noreply.github.com>
Adds real-MXC regression coverage for ProcessContainer token isolation, including an unsandboxed SCM positive control, and documents the AppContainer authorization model.
Validate raw OPA object and array containers before normalization and
access-preset expansion can skip malformed values. Return one fixed
structural error without embedding authored policy data.
Preserve versionless and runtime-only OPA data and existing semantic
validation. Cover initial string/file loading, middleware callback order,
valid deny-rule enforcement, and rejected reload state and generation.
Document the loader contract and its engine-local rejection behavior.
Signed-off-by: Shiju <shiju@nvidia.com>
Previously, metadata events omitted both HTTP request and response objects,
early proxy rejections used HTTP Activity without request context, and
unsupported-scheme events did not expose enough safe HTTP context to satisfy
the OCSF 1.8 schema.
Now, metadata events include a method-only request and their actual HTTP
response codes without recording the metadata URL. Unsupported-scheme events
also include a method-only request plus the generated 400 response. Authority
mismatches and credential-resolution denials use HTTP Activity with their
generated 403 or 500 responses, and HTTP activity IDs are derived from the
request method.
Additionally, HttpActivityBuilder now enforces the OCSF request-or-response
constraint at compile time.
Signed-off-by: Kris Hicks <khicks@nvidia.com>
* feat(api): expose structured gateway errors across SDKs
Refs #3051. Add standard validation, conflict, and retry details; preserve raw transport status in Rust, Go, TypeScript, and Python; document status and recovery guidance.
This is the structured-error foundation only. Mutation result shapes, allow_missing, durable request deduplication, and exec retry semantics remain follow-up work.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
* fix(python): preserve wrapped RPC cleanup handling
Inspect the original gRPC call when handling missing sandboxes during deletion waits and managed cleanup. Add intercepted cleanup regressions and clarify the error-wrapper migration contract.
Addresses the cleanup review on #3313; part of #3051.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
---------
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Evan Lezar