Lxd: Installation via apt-get automatically adds user to lxd group

[Reboare]

Required information

• Distribution: Ubuntu
• Distribution version: 16.04
  
  
  
  • Kernel version: 4.10.0-28-generic
  
  
  • LXC version: 2.0.8
  
  
  • LXD version: 2.0.10
  
  
  • Storage backend in use: dir
  
  

Issue description

Installation via apt-get on the above distribution leads to the user at uid:1000 being added to the lxd group. This effectively grants sudo-less root access to that user, an example of exploitation of which can be seen here #2003 .

Whilst this is understandably a design decision, the addition of the group should be opt-in, or a warning should be given upon installation as this is effectively granting full root access to an arbitrary user upon installation.

Steps to reproduce

1. run sudo apt-get install lxd
2. Assuming uid 1000 user is ubuntu groups ubuntu will show as being a member of the lxd group

ubuntu@ubuntu:~$ cat /etc/passwd | grep 1000
ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash
ubuntu@ubuntu:~$ cat /etc/group | grep ubuntu
adm:x:4:syslog,ubuntu
cdrom:x:24:ubuntu
sudo:x:27:ubuntu
dip:x:30:ubuntu
plugdev:x:46:ubuntu
lpadmin:x:113:ubuntu
ubuntu:x:1000:
sambashare:x:128:ubuntu
ubuntu@ubuntu:~$ sudo su
[sudo] password for ubuntu: 
root@ubuntu:/home/ubuntu# apt-get install lxd
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  liblxc1 lxc-common lxcfs lxd-client uidmap
Suggested packages:
  criu lxd-tools
The following NEW packages will be installed:
  liblxc1 lxc-common lxcfs lxd lxd-client uidmap
0 upgraded, 6 newly installed, 0 to remove and 136 not upgraded.
Need to get 5,622 kB of archives.
After this operation, 26.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 lxc-common amd64 2.0.8-0ubuntu1~16.04.2 [28.8 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 liblxc1 amd64 2.0.8-0ubuntu1~16.04.2 [215 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 lxd-client amd64 2.0.10-0ubuntu1~16.04.2 [1,857 kB]
Get:4 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 lxcfs amd64 2.0.7-0ubuntu1~16.04.2 [39.1 kB]
Get:5 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 uidmap amd64 1:4.2-3.1ubuntu5.3 [64.8 kB]
Get:6 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 lxd amd64 2.0.10-0ubuntu1~16.04.2 [3,416 kB]
Fetched 5,622 kB in 10s (540 kB/s)                                             
Preconfiguring packages ...
Selecting previously unselected package lxc-common.
(Reading database ... 175214 files and directories currently installed.)
Preparing to unpack .../lxc-common_2.0.8-0ubuntu1~16.04.2_amd64.deb ...
Unpacking lxc-common (2.0.8-0ubuntu1~16.04.2) ...
Selecting previously unselected package liblxc1.
Preparing to unpack .../liblxc1_2.0.8-0ubuntu1~16.04.2_amd64.deb ...
Unpacking liblxc1 (2.0.8-0ubuntu1~16.04.2) ...
Selecting previously unselected package lxd-client.
Preparing to unpack .../lxd-client_2.0.10-0ubuntu1~16.04.2_amd64.deb ...
Unpacking lxd-client (2.0.10-0ubuntu1~16.04.2) ...
Selecting previously unselected package lxcfs.
Preparing to unpack .../lxcfs_2.0.7-0ubuntu1~16.04.2_amd64.deb ...
Unpacking lxcfs (2.0.7-0ubuntu1~16.04.2) ...
Selecting previously unselected package uidmap.
Preparing to unpack .../uidmap_1%3a4.2-3.1ubuntu5.3_amd64.deb ...
Unpacking uidmap (1:4.2-3.1ubuntu5.3) ...
Selecting previously unselected package lxd.
Preparing to unpack .../lxd_2.0.10-0ubuntu1~16.04.2_amd64.deb ...
Adding system user `lxd' (UID 121) ...
Adding new user `lxd' (UID 121) with group `nogroup' ...
Creating home directory `/var/lib/lxd/' ...
Adding group `lxd' (GID 129) ...
Done.
Unpacking lxd (2.0.10-0ubuntu1~16.04.2) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up lxd-client (2.0.10-0ubuntu1~16.04.2) ...
Setting up lxcfs (2.0.7-0ubuntu1~16.04.2) ...
Setting up uidmap (1:4.2-3.1ubuntu5.3) ...
Setting up liblxc1 (2.0.8-0ubuntu1~16.04.2) ...
Setting up lxd (2.0.10-0ubuntu1~16.04.2) ...

The default LXD bridge, lxdbr0, comes unconfigured by default.
Only limited HTTP connectivity through a PROXY will be available.
To go through the initial LXD configuration, run: lxd init

Setting up lxc-common (2.0.8-0ubuntu1~16.04.2) ...
Processing triggers for systemd (229-4ubuntu19) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for libc-bin (2.23-0ubuntu9) ...
root@ubuntu:/home/ubuntu# cat /etc/passwd | grep 1000
ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash
root@ubuntu:/home/ubuntu# cat /etc/group | grep ubuntu
adm:x:4:syslog,ubuntu
cdrom:x:24:ubuntu
sudo:x:27:ubuntu
dip:x:30:ubuntu
plugdev:x:46:ubuntu
lpadmin:x:113:ubuntu
ubuntu:x:1000:
sambashare:x:128:ubuntu
lxd:x:129:ubuntu

[stgraber]

The LXD postinst adds members of the "sudo" group to the "lxd" group, so there's no security risk at all as those users are already allowed to become root.

This isn't opt-in because the group name is part of the systemd unit and LXD command line. It would be against packaging policy to have LXD alter those files post-install.

This is also consistent with what libvirt does with the libvirtd group.

[initstring]

Hi folks,

I know this is an old issue, but I think this needs closer attention as the current API still turns users into root without clearly stating this in the documentation.

_"That being said, I don't think it's a security issue as we consider anyone having access to the LXD API to have full root access anyway."_ (quote from here)

While you may consider that, an administrator may NOT consider that and I don't think it is fair for the LXD team to make that decision for anyone else. In fact, the documentation here states:

_"If the "lxd" group is missing on your system, create it, then restart the LXD daemon. You can then add trusted users to it. Anyone added to this group will have full control over LXD."_

I would recommend at least making a very large statement here that anyone added to this group will have full root access to the system, without the need to re-enter their password as is best practice for sudo users.

A user who closely follows the directions to create low-privilege containers is probably security conscious, but ends up giving their normal user account these root privileges.

Attackers generally work in a phased approach to compromise a system. One of their footholds may be a user in the LXD group. If that account is compromised, there are no further barriers to escalate to root.

Even a sudo user would require a password to be re-entered at this point, which the attacker may not have. Worse, this attack vector is still valid for non-sudo users who are in the lxd group.

A better design would match privileges of the calling user to the resources they can access, but I understand that is a heavy lift.

[Stoo0rmq]

Hi folks,

I know this is an old issue, but I think this needs closer attention as the current API still turns users into root without clearly stating this in the documentation.

_"That being said, I don't think it's a security issue as we consider anyone having access to the LXD API to have full root access anyway."_ (quote from here)

While you may consider that, an administrator may NOT consider that and I don't think it is fair for the LXD team to make that decision for anyone else. In fact, the documentation here states:

_"If the "lxd" group is missing on your system, create it, then restart the LXD daemon. You can then add trusted users to it. Anyone added to this group will have full control over LXD."_

I would recommend at least making a very large statement here that anyone added to this group will have full root access to the system, without the need to re-enter their password as is best practice for sudo users.

A user who closely follows the directions to create low-privilege containers is probably security conscious, but ends up giving their normal user account these root privileges.

Attackers generally work in a phased approach to compromise a system. One of their footholds may be a user in the LXD group. If that account is compromised, there are no further barriers to escalate to root.

Even a sudo user would require a password to be re-entered at this point, which the attacker may not have. Worse, this attack vector is still valid for non-sudo users who are in the lxd group.

A better design would match privileges of the calling user to the resources they can access, but I understand that is a heavy lift.

Absolutely agree with you mate.

[initstring]

@Stoo0rmq - the LXD team responded to me in another thread and have since updated the documentation to have some clear warnings on this, just FYI.
Thanks!

[Stoo0rmq]

Thanks to you man. I already checked your github + personal page. Really good working research!

[ssh3ll]

@Stoo0rmq - the LXD team responded to me in another thread and have since updated the documentation to have some clear warnings on this, just FYI.
Thanks!

It's viable nowadays, too.