Disable root, absolutely require password for 'ubuntu'


I’ve been testing for the last few days a public server in a container (LXC) on a DigitalOcean droplet running Ubuntu 18.04 (kernel 4.15.0-22-generic).

Everything works fine, except that I cannot imagine that someone who might eventually access the host to simply log into the container and have root or root-like permissions on its content that easily.

Right now, there is a default user ‘ubuntu’ that can login and do everything it wants due to its default sudo priviledges (‘lxc exec webserver – sudo --login --user ubuntu’) and there is the root user (lxc exec webserver – /bin/bash) which is just as lethal as the first.

I tried to set a password for the user ‘ubuntu’ and the hashed password appears in /etc/shadow, which means that it has been recoreded, but is not required whenever ‘ubuntu’ logs in.

Creating a new user didn’t help, this can also login without a password. True, it doesn’t have sudo permissions and cannot do much harm (“sudo: no tty present and no askpass program specified”), but it doesn’t help.

Is it possible to set and actually require a password for the default user ‘ubuntu’ and to also disable ‘root’ login inside a container?

Thank you.

lxc exec executes a command directly into the container as the root user, the kernel doesn’t have a concept of authentication so there’s no prompt there.

Make sure you don’t give access to the lxc command to anyone who you don’t want to have root access to all containers (and to the host). To give access to other users to your containers, the best is to just use plain old SSH which will go through the normal userspace authentication stack of the container.

1 Like

It’s amazing because, without knowing all the details that you briefly described about how lxc works, I came to the same conclusion:

Install and configure a SSH server in the container, configure the firewall to redirect external packets coming to a specific port to the IP address and SSH port of the container, then test and --if everything is ok-- restrict lxc usage (i.e. login options) on the host using /etc/sudoers, so that no one would be allowed to run commands that permit to reach the container from the host. Taking all these into consideration, and also that the SSH private key will be password-protected, I am trying to imagine that this would be a pretty safe workaround (config).

As soon as I am done (this will be a couple of days), I will report back, just to confirm.

Thank you!

Solved the problem in a different way, that is by changing /usr/bin/lxc file permissions from 755 to 750. Now others cannot execute the file. The administrator of the machine, as a member of the sudo group can, however he needs to provide a password first.

But all other users can just download and run their own copy of the lxc binary or can just talk directly to the LXD API without using the binary at all.

You can also do

lxc launch ubuntu:18.04 mycontainer
lxc exec mycontainer -- rm -fr /

but that mess will be confined in the container. And then, you can

lxc stop --force mycontainer
lxc delete mycontainer

and the container is gone, without affected the system in any way.

That is, whatever happens in a container, stays in the container.

Normally, I would avoid giving access to the host that has LXD.
On the host that has LXD, you need a password to do sudo su -.
If you have a non-root account on the host, then you can remove their membership from the lxd group.
It is the membership to the lxd group that gives the privilege to non-root accounts on the host to access fully the LXD installation.

1 Like

Thank you, all.

The host has one user and that is me. I only connect through SSH over VPN and my ssh private key also requires a password on the client. Under no circumstances I would give others access to the host, but I want to make sure that if someone escapes on the host (I don’t know how, I just imagine that), he won’t be able to launch lxc or lxd without being asked for another (second) password.

Thanks to Simos’ answer, I am thinking about changing lxd permissions to 750 too and also removing my username from the lxd group. I could still execute lxd commands whenever necessary due to my sudo group membership.

I am not sure whether I have to place more restrictions on /usr/bin (restrict even more tools such as wget, curl / restrict access to the entire directory) or I have become too paranoid. :frowning:

It would be a very very big thing if there was an escape from an unprivileged container.
There is some background at https://gist.github.com/FrankSpierings/5c79523ba693aaa38bc963083f48456c with a collection of resources on container security.

The container by default can make network connections to the host, to those services on the host that bind to all network interfaces (or just lxdbr0).
If the container has IP address, then the container can ping and nmap the host at the IP address Therefore, perform a network scan from a container to check what network services of the host are accessible to containers.

By default you would get to port 53 (LXD’s dnsmasq) and possibly the host’s OpenSSH server.
If there are any security vulnerabilities to any of these, then the unattended-upgrades of the host will install the updates automatically as soon as they get available.

With LXD 3, it is possible to not set up any networking on a container. You can configure the proxy device for this container so that the container would only respond connections from the Internet on specific ports. It is an option, however it also means that the container may not be able to perform unattended-upgrades.

1 Like

First of all, my apologies for the late answer.

It seems there’s some stuff left to play with. :slight_smile: I’ll do some scanning to see if there are any services left on the host that are listening on all interfaces, though I don’t think so, and to also see what the tracing tools can reveal about the host from within the containers.

Thank you very much for all the info and for your time! And by the way: I am now into LXD because of your tutorials on digitalocean.com.

Much appreciated!

Is there any development on this? Can we disable lxc exec command or authenticate using password protection?