Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify fstype when mounting filesystems #724

Closed
simondeziel opened this issue Jun 13, 2023 · 0 comments · Fixed by #725
Closed

Specify fstype when mounting filesystems #724

simondeziel opened this issue Jun 13, 2023 · 0 comments · Fixed by #725
Assignees

Comments

@simondeziel
Copy link
Contributor

There would be a (albeit small) security benefit in specifying which fstype we expect mount to use when trying to mount files obtained from external/untrusted sources. Here's the discussion I had on #ubuntu-security (mdeslaur is a member of the security team at Canonical):

sdeziel: Hello o/, I have a tool that runs as root and mount -o ro ISOs retrieved from external sources. I know that comes with a bunch of risks on its own but I'm wondering if there would be some benefits in specifying the fstype to use (mount -t iso9660 -o ro ...) to avoid mount (or the kernel?) having to (wrongly?) guess the fstype?
mdeslaur: sdeziel: filesystem flaws are common, if you specify it, you make sure someone isn't trying to exploit a known vulnerability in some arbitrary filesystem
sdeziel: mdeslaur: thanks!
mdeslaur: I guess that would reduce exposure a bit

I checked LXD code base, and it has helper functions always specifying the fstype so maybe there is a possibility of code reuse/copy here.

@monstermunchkin monstermunchkin self-assigned this Jun 14, 2023
monstermunchkin added a commit to monstermunchkin/distrobuilder that referenced this issue Jun 14, 2023
Fixes lxc#724

Signed-off-by: Thomas Hipp <thomas.hipp@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants