[lxc-users] lxc-2.0.1 can't start unprivileged container

[Stéphane Graber]

On Thu, Jun 09, 2016 at 02:27:44PM -0700, Mike Wright wrote:
> On 06/09/2016 01:13 PM, Stéphane Graber wrote:
> >On Thu, Jun 09, 2016 at 12:56:55PM -0700, Mike Wright wrote:
> >>On 06/09/2016 12:40 PM, Stéphane Graber wrote:
> >>>Sounds like your host /proc is over-mounted which triggers a protection
> >>>mechanism in the kernel that prevents an unprivileged user from mounting
> >>>it.
> >>>
> >>>Look in your host's /proc/mounts for any mountpoint under /proc, try
> >>>unmounting them one by one until you find the one that's triggering the
> >>>protection.
> >>
> >>Thanks Stéphane,
> >>
> >>Here's what's there:
> >>
> >>grep proc /proc/mounts:
> >>
> >>proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> >>
> >>systemd-1 /proc/sys/fs/binfmt_misc autofs
> >>rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
> >>
> >>xenfs /proc/xen xenfs rw,relatime 0 0
> >>
> >>I don't think I can safely remove any of those.  Any other ideas?
> >
> >I don't expect either of use to be in active constant use, so you can
> >still try unmounting them temporarily.
> >
> >An alternative is to mount /proc somewhere else on the host where it's
> >not hidden by those mounts.
> >
> >For example:
> >  - mkdir /mnt/proc
> >  - mount -t proc proc /mnt/proc
> 
> Success!
> 
> Created /alt/proc and mounted another proc there.  Unprivileged container
> started.  But I don't understand.
> 
> Don't the multiple procs conflict with each other in any way?  How did lxc
> find the correct proc to use?
> 
> There were two privileged containers running already without problems, and I
> used to run some unprivileged containers with lxc-1.
> 
> Do I just accept this as a new fact of life with lxc and add a mount proc
> line to fstab?
> 
> (Sorry for being dimwitted).

It's got nothing to do with LXC. It's a kernel security mechanism.

Unprivileged users cannot mount a filesystem which is already mounted
and which has paths "hidden" by another mount.

So if you just had /proc mounted with nothing on /proc/xen and
/proc/sys/fs/binfmt_misc, the kernel would have allowed the container to
mount proc just fine.

Because you had paths "hidden" from your host's /proc, the kernel
prevented the mount as it would have "exposed" the hidden paths to a
privileged user.



99% of the time, this check is basically a false positive. Yes, files
are hidden by those mounts, but that's perfectly normal and nothing
security sensitive is hidden by them.

In such case, mounting a new copy of the filesystem (proc in this case)
without the over-mounting, makes it so that the unprivileged user owning
the container can see the entirety of the filesystem and so the kernel
allows it to mount new copies of it.


This typically affects proc and sys. It's reasonably rare that it
affects containers running directly on the host but it does very
frequently (if not always) affect container nesting. Which is why the
LXC nesting configuration sets up a clean mount of proc and sys for you.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160609/f71ee8c8/attachment.sig>