Skip to content

Test that denied paths stay hidden through their aliases in the native-host backend - #416

Closed
Enrique Saurez (esaurez) wants to merge 1 commit into
esaurez/edge-nvxhost-proxyfrom
esaurez/edge-nvxhost-denied-aliases
Closed

Enrique Saurez (esaurez) wants to merge 1 commit into
esaurez/edge-nvxhost-proxyfrom
esaurez/edge-nvxhost-denied-aliases

Conversation

@esaurez

Copy link
Copy Markdown
Contributor

Summary

Stacked on #414. Adds a native-host guest test that denied paths stay hidden through their aliases, the cases MXC lists for the direct runtime, and documents what it shows. There is no code change: the library, guest, OpenVMM, and the private contract pin are unchanged.

  • New ignored guest test denied_paths_stay_hidden_through_aliases. One read-write mapping holds a denied directory and a denied file. The guest's report must match exactly:
    • .. into the denied directory, and back in from above the mapping: EACCES;
    • host links: a relative control link to an allowed file reads it; relative links into the denied directory and to the denied paths fail with EACCES; an absolute link fails with EACCES on Linux and EPERM on Windows, where OpenVMM never reads absolute targets for the guest; a Windows junction fails with EPERM;
    • a host hard link to the denied file: EACCES, because OpenVMM also refuses the denied object's identity;
    • links and a hard link that the workload creates in the mapping;
    • renaming over or away from the denied file, removing it, and creating a directory inside the denied directory: EACCES, and the host files are unchanged afterwards.
  • Two limits the test pins down. OpenVMM knows only the denied objects themselves:
    • a host hard link that joins a file inside a denied directory to a name outside it stays readable through that name;
    • the guest cannot list a directory that holds a host hard link to a denied file, because a listing looks up every entry.
  • README. The native section describes the alias behavior and both limits. The shared "Host paths" section no longer says that denied paths are inaccessible through every name.

Validation (head b5c07fa)

  • Guest suite, 20 tests, --release --test-threads=1: all pass on Windows/WHP and on Linux/MSHV, with the proxy stack's library and guest.
  • cargo fmt and Clippy with -D warnings on all targets with nvxhost,testing,async, on Windows and Linux.

Notes

  • On Windows the test creates symbolic links, which needs Developer Mode or the symbolic-link privilege; it fails with that message otherwise.

A new guest test maps a read-write directory that holds a denied directory and
a denied file. It adds host links, a junction on Windows, and host hard links,
and has the workload try `..`, those aliases, links of its own, and renames,
removals, and creations at the denied names. The guest resolves every link
itself, so each lookup of a denied path, or of another name for a denied
object, fails, and absolute Windows links and junctions cannot be followed.

OpenVMM knows only the denied objects themselves: a host hard link to a file
inside a denied directory stays readable, and a directory that holds a host
hard link to a denied file cannot always be listed. The README says so, and
no longer claims that a denied path is inaccessible through every name.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@esaurez

Copy link
Copy Markdown
Contributor Author

Superseded by #418, which carries this change on dev as part of the whole native-host edge backend, over nanvix/openvmm#121, and is validated end to end on WHP and MSHV. Closing.

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