| Message ID | 20191025112917.22518-1-mszeredi@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | allow unprivileged overlay mounts | expand |
On Fri, Oct 25, 2019 at 1:30 PM Miklos Szeredi <mszeredi@redhat.com> wrote: > > Hi Eric, > > Can you please have a look at this patchset? > > The most interesting one is the last oneliner adding FS_USERNS_MOUNT; > whether I'm correct in stating that this isn't going to introduce any > holes, or not... Forgot the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#ovl-unpriv Thanks, Miklos
Miklos Szeredi <mszeredi@redhat.com> writes: > Hi Eric, > > Can you please have a look at this patchset? > > The most interesting one is the last oneliner adding FS_USERNS_MOUNT; > whether I'm correct in stating that this isn't going to introduce any > holes, or not... I will take some time and dig through this. From a robustness standpoint I worry about the stackable filesystem side. As that is uniquely an attack vector with overlayfs. There is definitely demand for this. > Thanks, > Miklos > > --- > Miklos Szeredi (5): > ovl: document permission model > ovl: ignore failure to copy up unknown xattrs > vfs: allow unprivileged whiteout creation > ovl: user xattr > ovl: unprivieged mounts > > Documentation/filesystems/overlayfs.txt | 44 +++++++++++++ > fs/char_dev.c | 3 + > fs/namei.c | 17 ++--- > fs/overlayfs/copy_up.c | 34 +++++++--- > fs/overlayfs/dir.c | 2 +- > fs/overlayfs/export.c | 2 +- > fs/overlayfs/inode.c | 39 ++++++------ > fs/overlayfs/namei.c | 56 +++++++++-------- > fs/overlayfs/overlayfs.h | 81 +++++++++++++++--------- > fs/overlayfs/ovl_entry.h | 1 + > fs/overlayfs/readdir.c | 5 +- > fs/overlayfs/super.c | 53 +++++++++++----- > fs/overlayfs/util.c | 82 +++++++++++++++++++++---- > include/linux/device_cgroup.h | 3 + > 14 files changed, 298 insertions(+), 124 deletions(-) Eric
On Fri, Oct 25, 2019 at 01:35:20PM +0200, Miklos Szeredi wrote: > On Fri, Oct 25, 2019 at 1:30 PM Miklos Szeredi <mszeredi@redhat.com> wrote: > > > > Hi Eric, > > > > Can you please have a look at this patchset? > > > > The most interesting one is the last oneliner adding FS_USERNS_MOUNT; > > whether I'm correct in stating that this isn't going to introduce any > > holes, or not... > > Forgot the git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#ovl-unpriv > > Thanks, > Miklos I've looked through it, seemed sensible to me. -serge
On Fri, Oct 25, 2019 at 3:43 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > Miklos Szeredi <mszeredi@redhat.com> writes: > > > Hi Eric, > > > > Can you please have a look at this patchset? > > > > The most interesting one is the last oneliner adding FS_USERNS_MOUNT; > > whether I'm correct in stating that this isn't going to introduce any > > holes, or not... > > I will take some time and dig through this. > > From a robustness standpoint I worry about the stackable filesystem > side. As that is uniquely an attack vector with overlayfs. > > There is definitely demand for this. Hi Eric, Have you had time to look into this yet? Thanks, Miklos
On Tue, 2019-10-29 at 12:01 -0500, Serge E. Hallyn wrote: > On Fri, Oct 25, 2019 at 01:35:20PM +0200, Miklos Szeredi wrote: > > On Fri, Oct 25, 2019 at 1:30 PM Miklos Szeredi <mszeredi@redhat.com > > > wrote: > > > Hi Eric, > > > > > > Can you please have a look at this patchset? > > > > > > The most interesting one is the last oneliner adding > > > FS_USERNS_MOUNT; > > > whether I'm correct in stating that this isn't going to introduce > > > any > > > holes, or not... > > > > Forgot the git tree: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#ovl- > > unpriv > > > > Thanks, > > Miklos > > I've looked through it, seemed sensible to me. Seems sensible to me too but I'm not sure what I'm looking for. Perhaps a bit more on how this is secure to give an idea what's been checked and where to focus so the the survey can be broadened from there... I'm not sure. For example, from my simple minded view I wonder about the posix acl code. In ovl_posix_acl_xattr_set() there is a call to posix_acl_from_xattr() that uses init_user_ns. I wonder if that should be the current user ns in this case but I'm not sure? Ian