linux-kernel - Re: [PATCH 0/1] shiftfs: uid/gid shifting filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160607110433.GB2765@dztty.fritz.box>
Date:	Tue, 7 Jun 2016 12:04:33 +0100
From:	Djalal Harouni <tixxdz@...il.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Michał Zegan <webczat_200@...zta.onet.pl>,
	Chris Mason <clm@...com>, tytso@....edu,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Josh Triplett <josh@...htriplett.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...nel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Dongsu Park <dongsu@...ocode.com>,
	David Herrmann <dh.herrmann@...glemail.com>,
	Miklos Szeredi <mszeredi@...hat.com>,
	Alban Crequy <alban.crequy@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH 0/1] shiftfs: uid/gid shifting filesystem

On Mon, Jun 06, 2016 at 03:02:30PM -0700, James Bottomley wrote:
> On Sun, 2016-06-05 at 22:11 +0100, Djalal Harouni wrote:
> > On Wed, Jun 01, 2016 at 12:41:00PM -0400, James Bottomley wrote:
> > > On Wed, 2016-06-01 at 18:21 +0200, Michał Zegan wrote:
> > > > As I sent a reply in a ... wrong way, I do it again. my question
> > > > was:
> > > > Why isn't it done at the vfs layer when you mount the fs in
> > > > different
> > > > userns, instead of using a separate filesystem for it?
> > > 
> > > Well, that is what this patch does:
> > > 
> > > http://thread.gmane.org/gmane.linux.kernel/2214882
> > > 
> > > However, the reason it doesn't work for me is that I want to be
> > > able to
> > > unpack the image into a subdirectory (so I'm not dedicating a whole
> > > filesystem for this).  This is primarily for a docker hack IBM is
> > > working on to allow each container instance to use a separate
> > > uid/gid
> > > range, so I need something that behaves much more like a bind
> > > mount.
> > I thought that you were using a loop device ?
> 
> No, for Architectural emulation containers, I use file roots, so
> they're subdirectories of my home directory.  The interesting issues
> Serge discovered are on ext4, which I needed a loop device to reproduce
> (my home directory is xfs) if that's where the confusion arises?
Ok then, but yeh for security it's better to have a different backing
store... it allows somehow to protect the host too...

> Thinking about containers in general, a significant amount use bind
> mounted file roots because that's a nice use case that hypervisors
> can't match without clusterable filesystems.  However, I do know some
> containers that are block image based, so whatever solution is chosen
> has to support both.
Yeh, but I may say that with overlayfs things changed a bit... actually
the bind mount of today is kind of overlayfs mount... that most
containers support by default, but yeh it solves the case of one shared
portable filesystem image that you shift mount on its different backing
store and use it as a lower layer for overlayfs to gain sharing
capabilities (hence why that RFC does the shift only when we need the
actual access...) and each container with its own upper layer... you
endup automatically by a default clean reset image and snapshots...


> >  that's precisely one of the main case that's solved with that 
> > solution... mount the portable fs image into a loop device, set the 
> > shift which will be only active into that subdirectory...
> > 
> > 
> > > >  I believe it could be useful to be able to mount all filesystems 
> > > > in userns with autoshifted uids, although I do not know security
> > > > implications for that usage.
> > > 
> > > As long as you don't need to subdivide the volume, it works nicely.
> > >  However, from a security point of view, that entire volume is now
> > > effectively freely writeable by anyone who can set up a userns.  If 
> > > you follow the shiftfs route, you can break off writeable
> > > subdirectories for each namespace shift, but they can't cross over 
> > > into writing subdirectories that belong to other user namespaces 
> > > (assuming the uids are fully segregated).
> > 
> > As said in the other email, I'm not really sure about the use case at
> > all... but I give you this quick test with:
> > https://gist.githubusercontent.com/tixxdz/6b84c2c3bd6cb987c82255602ec
> > 70f23/raw/97c9ab76878f9d7415583c00b22ca0e4a948847b/userns_test.c
> > 
> > $ mkdir shifted-fedora-tree && sudo mount -t shiftfs 
> > -ouidmap=0:1000000:65536,gidmap=0:1000000:65536 ~/fedora-tree/
> > shifted-fedora-tree
> 
> This is basically what I do for my container roots.  However, after
> that I tend to set them up with scripts.  I've attached my latest build
> -container script at the bottom.  As you can see from my script, all my
> build containers are in /home/jejb/containers.
Ok, thanks!

-- 
Djalal Harouni
http://opendz.org