My question is around the security of an LXC container.

If I am running multiple containers on my box, and give users a separate ssh access to their owned container, can any of those container hack into the other containers on that box or the even the host machine?

Where are lxc containers security borderlines?

  • you know need to worry about that , AppArmor will take care of that. – rɑːdʒɑ Sep 7 '13 at 1:01

As I have seen about LXC It stores container information and (with the default backing store) root filesystems under /var/lib/lxc. Container creation templates also tend to store cached distribution information under /var/cache/lxc.

So Generally access to root filesystem only allowed to admin unless there is a misusage or wrong configuration user profiles while creating them.

But Ubuntu Developers may already came to this point and they have provided a secure solution with the help of AppArmor.

LXC ships with an Apparmor profile intended to protect the host from accidental misuses of privilege inside the container. For instance, the container will not be able to write to /proc/sysrq-trigger or to most /sys files.

The usr.bin.lxc-start profile is entered by running lxc-start. This profile mainly prevents lxc-start from mounting new filesystems outside of the container's root filesystem. Before executing the container's init, LXC requests a switch to the container's profile. By default, this profile is the lxc-container-default policy which is defined in /etc/apparmor.d/lxc/lxc-default. This profile prevents the container from accessing many dangerous paths, and from mounting most filesystems.

If you find that lxc-start is failing due to a legitimate access which is being denied by its Apparmor policy, you can disable the lxc-start profile by doing:

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/

This will make lxc-start run unconfined, but continue to confine the container itself. If you also wish to disable confinement of the container, then in addition to disabling the usr.bin.lxc-start profile, you must add:

lxc.aa_profile = unconfined

to the container's configuration file. If you wish to run a container in a custom profile, you can create a new profile under /etc/apparmor.d/lxc/. Its name must start with lxc- in order for lxc-start to be allowed to transition to that profile. After creating the policy, load it using:

sudo apparmor_parser -r /etc/apparmor.d/lxc-containers

The profile will automatically be loaded after a reboot, because it is sourced by the file /etc/apparmor.d/lxc-containers. Finally, to make container CN use this new lxc-CN-profile, add the following line to its configuration file:

lxc.aa_profile = lxc-CN-profile

lxc-execute does not enter an Apparmor profile, but the container it spawns will be confined.

| improve this answer | |
  • Many thanks for your answer. So, are you saying it is secure if I use AppArmor? – iCode Sep 7 '13 at 1:13
  • @iCode , Yes appArmor designed for protecting Ubuntu applications and LXC also getting great support in terms of security if you use AppArmor. – rɑːdʒɑ Sep 7 '13 at 1:41
  • AppArmor is not everything, for example I found that dmesg can be called from any container (at least in the default config). I'm afraid that's not the only security risk... – Daniel Alder May 20 '15 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.