Package: lxc Version: 1:1.0.6-6+deb8u3 Severity: important To reproduce:
root@debian-host# lxc-create -n bb -t busybox root@debian-host# cat /var/lib/lxc/bb/config lxc.network.type = empty lxc.rootfs = /var/lib/lxc/bb/rootfs lxc.haltsignal = SIGUSR1 lxc.utsname = bb lxc.tty = 1 lxc.pts = 1 lxc.cap.drop = sys_module mac_admin mac_override sys_time lxc.mount.entry = /lib lib none ro,bind 0 0 lxc.mount.entry = /usr/lib usr/lib none ro,bind 0 0 lxc.mount.entry = /lib64 lib64 none ro,bind 0 0 lxc.mount.entry = /sys/kernel/security sys/kernel/security none ro,bind,optional 0 0 lxc.mount.auto = proc:mixed sys root@debian-host# lxc-start -n bb -d root@debian-host# lxc-attach -n bb touch /lib/test-file root@debian-host# ls -l /lib/test-file && rm -f /lib/test-file -rw-r--r-- 1 root root 0 Sep 15 16:57 /lib/test-file I.E., where the lxc config specifies "ro,bind" for the bind mounts, in fact only the "bind" flag is honoured, and filesystems are mounted read/write. That's because of this passage in the mount(2) manpage: MS_BIND (Linux 2.4 onward) Perform a bind mount, making a file or a directory subtree visi- ble at another point within a filesystem. Bind mounts may cross filesystem boundaries and span chroot(2) jails. The filesystem- type and data arguments are ignored. Up until Linux 2.6.26, >>>mountflags was also ignored<<< (the bind mount has the same mount options as the underlying mount point). Apparently, this behaviour (respect MS_BIND, _silently_ ignore other flags) is still present in recent kernels, and is (IMO) a bug in itself. As a result, people are misled into thinking they can use LXC to build sandboxes, perhaps by dropping the SYS_ADMIN capability in the containers, yet commands performed by root inside such a container (think dpkg -i/-r, or rm -rf or ...) may cause considerable damage to the host system, unless uid/gid remapping is enforced. The bug in mount(2) can be verified in debian/jessie e.g. by running # mkdir /tmp/xyz-lib; mount -o ro,bind /lib /tmp/xyz-lib which leaves /lib mounted r/w as /tmp/xyz-lib. Recent versions of the mount(1) command work around the bug in mount(2) by calling it twice, once with the MS_BIND flag, and then with the other user-specified flags. It is not an ideal solution (implies a race condition), yet the end result is correct. As to LXC, I believe the problem was fixed upstream by this commit: https://github.com/lxc/lxc/commit/7c5b6e7c3524031c3e9e203a9ab3beea7efa7a41 which implements the double call to mount(2), and AFAICT is included in lxc-1.0.7. Therefore, I suggest to rebase the debian/jessie lxc sources on lxc-1.0.7, instead of lxc-1.0.6. Best regards, giuseppe -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lxc depends on: ii init-system-helpers 1.22 ii libapparmor1 2.9.0-3 ii libc6 2.19-18+deb8u6 ii libcap2 1:2.24-8 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-2 ii multiarch-support 2.19-18+deb8u6 ii python3 3.4.2-2 Versions of packages lxc recommends: ii debootstrap 1.0.67 ii openssl 1.0.1t-1+deb8u5 ii rsync 3.1.1-3 Versions of packages lxc suggests: pn lua5.2 <none> -- no debconf information