Search code examples
lxcapparmor

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


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 ?


Solution

  • 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.