Re: [RFC PATCH 0/0] VFS:userns: support portable root filesystems

[Djalal Harouni]

Hi,

On Wed, May 04, 2016 at 08:34:04AM -0500, Seth Forshee wrote:
> On Wed, May 04, 2016 at 01:21:46AM +0200, Djalal Harouni wrote:
> > This RFC tries to explore how to support filesystem operations inside
> > user namespace using only VFS and a per mount namespace solution. This
> > allows to take advantage of user namespace separations without
> > introducing any change at the filesystems level. All this is handled
> > with the virtual view of mount namespaces.
> > 
> > 
> > 1) Presentation:
> > ================
> > 
> > The main aim is to support portable root filesystems and allow containers,
> > virtual machines and other cases to use the same root filesystem.
> > Due to security reasons, filesystems can't be mounted inside user
> > namespaces, and mounting them outside will not solve the problem since
> > they will show up with the wrong UIDs/GIDs. Read and write operations
> > will also fail and so on.
> > 
> > The current userspace solution is to automatically chown the whole root
> > filesystem before starting a container, example:
> > (host) init_user_ns  1000000:1065536  => (container) user_ns_X1 0:65535
> > (host) init_user_ns  2000000:2065536  => (container) user_ns_Y1 0:65535
> > (host) init_user_ns  3000000:3065536  => (container) user_ns_Z1 0:65535
> > ...
> > 
> > Every time a chown is called, files are changed and so on... This
> > prevents to have portable filesystems where you can throw anywhere
> > and boot. Having an extra step to adapt the filesystem to the current
> > mapping and persist it will not allow to verify its integrity, it makes
> > snapshots and migration a bit harder, and probably other limitations...
> > 
> > It seems that there are multiple ways to allow user namespaces combine
> > nicely with filesystems, but none of them is that easy. The bind mount
> > and pin the user namespace during mount time will not work, bind mounts
> > share the same super block, hence you may endup working on the wrong
> > vfsmount context and there is no easy way to get out of that...
> > 
> > Using the user namespace in the super block seems the way to go, and
> > there is the "Support fuse mounts in user namespaces" [1] patches which
> > seem nice but perhaps too complex!? there is also the overlayfs solution,
> > and finaly the VFS layer solution.
> 
> I'm not sure if you're meaning to propose your patches as an alternative
> to mine or not, but I think they're orthogonal. My goal is to allow
> containers in user namespaces to mount some subset of filesystem types

I see. Yes I didn't think that much about mounting filesystems inside
user namespaces, and that's not the mainly use case here for sure.

> (not specifically container root filesystems, but in general), which
> your patches won't enable. Your goal is to share a rootfs between
> multiple containers with different uid/gid shifts, which my patches
> don't help with.
The aim with these patches is containers but not only that.

Basically it goes to every situations where you need user namespaces
for some separation but UIDs/GIDs will end up with the wrong identity.
So yes sharing rootfs but also to give the correct UIDs/GIDs mapping
inside user namespaces.

Maybe both can be combined ? I checked your series lately but to be
honest I'm not that familiar with the use case. This one is just an RFC
for the moment, and ultimatly it's designed to stay *deep* inside *VFS*.
Nothing is exposed even the flags inside the super_block are internal
flags, the VFS should do the work for us, and maybe XFS and rare cases
will have to call VFS helpers but that's it. So I tried as much as
possible to let the thing flexible, and at the same time hide the
details and use existing interfaes, so yes maybe something can be worked
out ?


> > We present here a simple VFS solution, everything is packed inside VFS,
> > filesystems don't need to know anything (except probably XFS, and special
> > operations inside union filesystems). Currently it supports ext4, btrfs
> > and overlayfs. Changes into filesystems are small, just parse the
> > vfs_shift_uids and vfs_shift_gids options during mount and set the
> > appropriate flags into the super_block structure.
> > 
> > 1) Filesystems don't need the FS_USERNS_MOUNT flag, so no user
> > namespace mounting, they stay secure, nothing changes.
> > 
> > 2) The solution is based on VFS and mount namespaces, we use the user
> > namespace of the containing mount namespace to check if we should shift
> > UIDs/GIDs from/to virtual <=> on-disk view.
> > If a filesystem was mounted with "vfs_shift_uids" and "vfs_shift_gids"
> > options, and if it shows up inside a mount namespace that supports VFS
> > UIDs/GIDs shifts then during each access we will remap UID/GID either
> > to virtual or to on-disk view using simple helper functions to allow the
> > access. In case the mount or current mount namespace do not support VFS
> > UID/GID shifts, we fallback to the old behaviour, no shift is performed.
> > 
> > 3) inodes will always keep their original values which reflect the
> > mapping inside init_user_ns which we consider the on-disk mapping.
> > Therfore they will have a mapping from 0:65536 on-disk, these values are
> > the persistent values that we have to write to the disk. We don't keep
> > track of any UID/GID shift that was applied before. This gives
> > portability and allows to use the previous mapping which was freed for
> > another root filesystem...
> 
> Sorry, I haven't had time to look at the patches, but how are you
> handling suid/sgid? Will the process get the ids in the inode or the
> shifted ids?
Hmm, what do you mean by this please ? 

I picked a patch from you series, the one that was written by Andy and
adapt it here so outsiders of the mount namespace and its user namespace
can't fool us. Please see patch 0003, but I'm sure that it needs a
better review as it is now just an RFC.

Thank you!


> Thanks,
> Seth
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Djalal Harouni
http://opendz.org