What does lxc-container-default-with-nesting AppArmor profile do?

Question

I'm using nested LXC with lxc-container-default-with-nesting profile which looks like the following.

profile lxc-container-default-with-nesting flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>
  #include <abstractions/lxc/start-container>

#  Uncomment the line below if you are not using cgmanager
#  mount fstype=cgroup -> /sys/fs/cgroup/**,

  deny /dev/.lxc/proc/** rw,
  deny /dev/.lxc/sys/** rw,
  mount fstype=proc -> /var/cache/lxc/**,
  mount fstype=sysfs -> /var/cache/lxc/**,
  mount options=(rw,bind),
}

and I have two questions about the following line.

  mount fstype=proc -> /var/cache/lxc/**,

1. Why is it safe to allow container to mount /proc ?

2. Why container needs to mount /proc under /var/cache/lxc ?

Answer 1

Nested Container Configuration

That config file allows you to create nested LXC containers, one inside another. By default, this is disabled since it bypasses some of the default cgroup restrictions (more info here).

In general, it changes apparmor rules to allow lxc to re-mount certain system resources (with certain restrictions) inside the container.

lxc.container.conf

If you look at man lxc.container.conf, this section explains settings you can edit for how proc is mounted. I think it uses proc:mixed by default (but I haven't confirmed this!)

  lxc.mount.auto
          specify which standard kernel file systems should be
          automatically mounted. This may dramatically simplify
          the configuration. The file systems are:

          · proc:mixed (or proc):
            mount /proc as read-write, but
            remount /proc/sys and
            /proc/sysrq-trigger read-only
            for security / container isolation purposes.

          · proc:rw: mount
            /proc as read-write

Unprivileged LXC

As an aside, if you're not using unprivileged LXC, you should be. Seriously. It adds an additional layer of protection that restricts what the root user in the container can do (It actually maps it to a non-root user outside the container). This provides an additional layer of protection for /proc in case something slips by the apparmour rules.

As far as why it uses /var/cache/lxc, I have no idea. A guess would be that it has to do with not conflicting with cgmanager. Looking at the source might be a good place to start if you're interested in the reasoning.