Skip to content

mnt: fail closed when explicit security mount flags cannot be applied - #334

Open
HazEOskA wants to merge 1 commit into
google:masterfrom
HazEOskA:fix/fail-closed-explicit-mount-flags
Open

HazEOskA wants to merge 1 commit into
google:masterfrom
HazEOskA:fix/fail-closed-explicit-mount-flags

Conversation

@HazEOskA

Copy link
Copy Markdown

Summary

Fail closed when explicit security mount flags cannot be applied by the new mount API path.

This hardens nsjail against continuing with a mount when explicitly requested security properties such as MS_NOSUID, MS_NODEV, or MS_NOEXEC could not actually be enforced.

Problem

applyMountFlags() failures are currently logged, but mount setup may continue.

For ordinary/non-security-related flags this can remain best-effort behavior, but when the configuration explicitly requests security-sensitive flags:

  • MS_NOSUID
  • MS_NODEV
  • MS_NOEXEC

continuing after the flag application fails means the resulting mount may not have the security properties requested by the nsjail configuration.

This is fail-closed hardening; I am not claiming a sandbox escape.

Fix

For the new mount API paths in mnt_newapi.cc:

  • detect failure from applyMountFlags()
  • if any explicitly requested security flag is present (MS_NOSUID | MS_NODEV | MS_NOEXEC), abort mount setup
  • close the mount file descriptor before returning
  • clean up the temporary dynamic-content source where applicable
  • return false so sandbox setup does not continue with weaker-than-requested mount semantics

Best-effort behavior is preserved for flag failures that do not involve these explicit security flags.

Scope

The change is intentionally narrow.

It affects only:

  • mountDynamicContentAt()
  • mountSinglePointAt()

in the new mount API implementation.

It does not modify the legacy mount path or unrelated mount behavior.

Security rationale

When a sandbox configuration explicitly requests a security property, silently continuing after that property cannot be applied creates a mismatch between configured and effective isolation.

Failing closed makes the effective sandbox state consistent with the requested security policy.

Validation

The patch was tested against the upstream baseline with focused failure injection.

Observed behavior:

Baseline

  • security mount flag application failure: observed
  • mount/sandbox setup continued: YES

Patched

  • security mount flag application failure: observed
  • mount/sandbox setup continued: NO
  • focused regression: PASS
  • verification: PASS

The patch contains only the fail-closed handling required for these explicit security mount flags.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant