shiftfs: lock security sensitive superblock flags
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Christian Brauner | ||
Disco |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Felix Abecassis from Nvidia recently reported the following bug:
"I recently upgraded to Ubuntu 19.04, and decided to experiment with shiftfs and unprivileged overlay.
My goal was to have root (in my case, the docker daemon) download overlay layers and then have multiple users leveraging shiftfs + unprivileged overlay to assemble the rootfs without copying and chowning.
For obvious security reasons, I want root to expose these layers as read-only, any change will be to the user-owned "upper" filesystem.
Here's what I'm currently doing:
# Exposing the root-owned docker layers, the "ro" option seems to have no impact on later userns mounts.
sudo mount -t shiftfs -o mark,ro /var/lib/
# Creating a userns as uid 1000, then mounting the shiftfs.
unshare -U -m -r
cd $(mktemp -d)
mkdir shiftfs upper work merged
# I can pass "ro" to the mount to get the behavior I want.
mount -t shiftfs -o ro /mnt shiftfs
mount -t overlay overlay -o 'lowerdir=
This works fine (excluding the xattrs issue with unprivileged overlay), but I can't rely on users to pass the "ro" option to their mounts. Without it, any user would be able to write to /var/lib/
I couldn't find a way to enforce do that, is there one? Is it possible to have one?
I quickly attempted to have root do the shiftfs mounts for the users, but it seems the shift is always for the root of the current userns, and can't be done for another user."
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
assignee: | nobody → Christian Brauner (cbrauner) |
status: | Confirmed → In Progress |
tags: | added: patch |
Changed in linux (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Disco): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu): | |
status: | Fix Committed → Fix Released |
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification- needed- disco' to 'verification- done-disco' . If the problem still exists, change the tag 'verification- needed- disco' to 'verification- failed- disco'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/ /wiki.ubuntu. com/Testing/ EnableProposed for documentation how to enable and use -proposed. Thank you!