[lxc-devel] [PATCH] [RFC] lxc: don't call pivot_root if / is on a ramfs

[Serge Hallyn]

Quoting Andrey Wagin (avagin at gmail.com):
> 2014-10-08 18:54 GMT+04:00 Serge Hallyn <serge.hallyn at ubuntu.com>:
> > Quoting Andrew Vagin (avagin at gmail.com):
> >> On Wed, Oct 08, 2014 at 05:26:03AM +0000, Serge Hallyn wrote:
> >> > Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> >> > > Quoting Andrey Vagin (avagin at openvz.org):
> >> > > > From: Andrey Vagin <avagin at gmail.com>
> >> > > >
> >> > > > pivot_root can't be called if / is on a ramfs. Currently chroot is
> >> > > > called before pivot_root. In this case the standard well-known
> >> > > > 'chroot escape' technique allows to escape a container.
> >> > > >
> >> > > > I think the best way to handle this situation is to make following actions:
> >> > > > * clean all mounts, which should not be visible in CT
> >> > > > * move CT's rootfs into /
> >> > > > * make chroot into /
> >> > > >
> >> > > > I don't have a host, where / is on a ramfs, so I can't test this patch.
> >> > > >
> >> > > > CAUTION: I am not sure that this way is secure.
> >> > >
> >> > > Thanks, Andrey.
> >> > >
> >> > > This is looking ok to me, with the only exception being that (at least
> >> > > when I test by hand) it looks like you need to bind-mount the root onto
> >> > > itself before doing the move mount.  (AFAIK we're not doing that before
> >> > > that in the chroot_into_slave path).
> >> > >
> >> > > We should also make sure to turn all mounts into slave before doing
> >> > > this, or some hosts will not be happy.
> >> >
> >> > So in the midst of all the other discussion going on, I'm thinking of
> >> > applying your path with the two needed fixes (bind-mount the root onto
> >> > itself first, and do the turn-into-slave first)
> >> >
> >> > Please shout if you have any objections or new input.
> >>
> >> Here is an updated patch.
> >
> > When I run just this as a test program, your chrootbreak2 still works
> > against it.
> 
> chrootbreak2 works for my previous version too. It was a reason, why I
> decided to fix the kernel.

Oh, ok.  Well there's only so much we can do I guess.

> > When I also chroot first, then the classic chrootbreak
> > works against it.
> 
> I don't understand this.

Oh, it's not particularly relevant.  That's just saying that if you
start out chrooted but on a ramfs, then container will be able to
escape to the real ramfs root using classic chroot escape.  (Test
program attached, but probably not interesting)

> >
> > If I take your previous version, using MS_MOVE, that'll still be ok
> > right?
> 
> Yes, that will.
> 
> The second version contains a few additional comments and it doesn't
> use a file descriptor to chroot in a CT root.

Ok, I'll tweak it and apply - thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cis7.c
Type: text/x-csrc
Size: 2246 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141008/621c1393/attachment.c>