Skip to content

[Bug Bash] microVM: set containerd's default masked and read-only paths - #3249

Merged
Tim Hockin (thockin) merged 7 commits into
agent-substrate:mainfrom
hdp617:microvm-masked-paths
Nov 1, 2026
Merged

Tim Hockin (thockin) merged 7 commits into
agent-substrate:mainfrom
hdp617:microvm-masked-paths

Conversation

@hdp617

@hdp617 Huy Pham (hdp617) commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Why is this needed? (Or link the issue. Open one first for features, API, install or CI changes.)

On microVM, an actor’s container runs as uid 0 in the guest kernel. Before this PR, the worker sent kata-agent empty masked and read-only path lists. That left the guest’s /proc/sys writable: the kernel lets uid 0 write sysctls without any capability.

The kata-agent skips masked paths that are directories. Of the five directories, only /proc/acpi and /sys/firmware exist in the kata 4.3.1 guest kernel. We mount read-only tmpfs similar to runc.

Breaking change: a uid 0 entrypoint can no longer write guest sysctls, such as sysctl -w vm.max_map_count=.... This already fails on gVisor. Goldens and checkpoints taken before this change keep a writable /proc/sys until they are re-taken.

Part of #3226.

AI use: AI-assisted, I reviewed and tested it.

  • Tests pass
  • Docs updated

@hdp617 Huy Pham (hdp617) changed the title microVM: set containerd's default masked and read-only paths [Bug Bash] microVM: set containerd's default masked and read-only paths Oct 26, 2026
@hdp617
Huy Pham (hdp617) marked this pull request as ready for review October 26, 2026 23:18
Comment thread internal/ocispec/microvm.go Resolved

@cheftako Walter Fender (cheftako) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this change a uid 0 container could tune guest sysctls at runtime, such as sysctl -w vm.max_map_count=..., vm.overcommit_memory or net.core.somaxconn. Entrypoints that do this and exit on failure will now crash. So if we want this change we should get it in prior to GA.

Comment thread internal/ocispec/microvm.go Resolved
@bowei Bowei Du (bowei) added the kind/bug Something isn't working / bugfixes label Oct 27, 2026
@hdp617

Copy link
Copy Markdown
Contributor Author

Before this change a uid 0 container could tune guest sysctls at runtime, such as sysctl -w vm.max_map_count=..., vm.overcommit_memory or net.core.somaxconn. Entrypoints that do this and exit on failure will now crash. So if we want this change we should get it in prior to GA.

That's fair. I added a note to the PR description for this.

@cheftako

Copy link
Copy Markdown
Contributor

/lgtm

Comment thread internal/ocispec/microvm.go Resolved

@thockin Tim Hockin (thockin) left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am approving -- Benjamin Elder (@BenTheElder) do we wait for dirs, too or merge this and consider followup. This is a subtle area.

A uid 0 container is root in the guest kernel, and with no read-only
paths it could write the guest's /proc/sys.

Signed-off-by: Huy Pham <[email protected]>
Any error passed before, so the test could pass when the write failed
for another reason.

Signed-off-by: Huy Pham <[email protected]>
Also list the read-only paths one per line, like the masked paths.

Signed-off-by: Huy Pham <[email protected]>
The gVisor write now has to fail with permission denied, so an error
like ENOENT no longer passes. On microVM, /proc/interrupts has to read
as empty, which shows the /dev/null mask is in force.

Signed-off-by: Huy Pham <[email protected]>
@hdp617

Copy link
Copy Markdown
Contributor Author

I am approving -- Benjamin Elder (Benjamin Elder (@BenTheElder)) do we wait for dirs, too or merge this and consider followup. This is a subtle area.

Thanks for looking into this. I think we should just do dirs now; I've adjusted the PR.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking follow-ups. Thanks!

Comment thread internal/ocispec/microvm.go Resolved
Comment thread internal/ocispec/microvm.go Resolved
Comment thread internal/ocispec/microvm_test.go Resolved
@dims

Copy link
Copy Markdown
Collaborator

Pass goarch into guestMaskedDirPaths so both arches are unit tested, and
say ShapeMicroVM applies a subset of containerd's masked paths.

Signed-off-by: Huy Pham <[email protected]>
@thockin
Tim Hockin (thockin) added this pull request to the merge queue Nov 1, 2026
Merged via the queue into agent-substrate:main with commit 4488a66 Nov 1, 2026
5 checks passed
Dmitry Berkovich (dberkov) pushed a commit that referenced this pull request Nov 2, 2026
…hs (#3249)

<!-- The PR title becomes the release note. Write it for users. -->

> Why is this needed? (Or link the issue. Open one first for features,
API, install or CI changes.)

On microVM, an actor’s container runs as uid 0 in the guest kernel.
Before this PR, the worker sent kata-agent empty masked and read-only
path lists. That left the guest’s `/proc/sys` writable: the kernel lets
uid 0 write sysctls without any capability.

The kata-agent skips masked paths that are directories. Of the five
directories, only `/proc/acpi` and `/sys/firmware` exist in the kata
4.3.1 guest kernel. We mount read-only tmpfs similar to
[runc](https://github.com/opencontainers/runc/blob/4ca628d1d4c974f92d24daccb901aa078aad748e/libcontainer/rootfs_linux.go#L1250-L1258).

**Breaking change**: a uid 0 entrypoint can no longer write guest
sysctls, such as `sysctl -w vm.max_map_count=...`. This already fails on
gVisor. Goldens and checkpoints taken before this change keep a writable
`/proc/sys` until they are re-taken.

Part of #3226.

<!-- e.g. "AI-assisted, I reviewed and tested it." No AI co-author
trailers. -->
AI use: AI-assisted, I reviewed and tested it.

<!-- Breaking change? Describe what users must do on upgrade and ask for
the `breaking-change` label. -->

- [x] Tests pass
- [ ] Docs updated

---------

Signed-off-by: Huy Pham <[email protected]>
(cherry picked from commit 4488a66)
Signed-off-by: Eitan Yarmush <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/microVM area/security Security related issue/pr kind/bug Something isn't working / bugfixes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants