Public bug reported:
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/docker/overlay2 /mnt
# 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=shiftfs/c34c048514dcab5fc1bddf6d99681645786021e4a5b239972ec688386852a666/diff:[...],upperdir=upper,workdir=work'
merged
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/docker/overlay2
through the shiftfs mountpoint.
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."
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1827122
Title:
shiftfs: lock security sensitive superblock flags
Status in linux package in Ubuntu:
In Progress
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/docker/overlay2 /mnt
# 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=shiftfs/c34c048514dcab5fc1bddf6d99681645786021e4a5b239972ec688386852a666/diff:[...],upperdir=upper,workdir=work'
merged
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/docker/overlay2 through the shiftfs mountpoint.
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."
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827122/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
