What does security.nesting=true?

Hi
Thanks again to the community (and namely Stéphane) for all the answers we - and I - get on this forum!

I was in real trouble with AppArmor of my Debian Buster Host trying to make Mariadb and Redis work in my Debian Buster container (with LXD 3.22). Neither Mariadb nor Redis could start and I was getting this on the host:

Mariadb:
apparmor=“DENIED” operation=“mount” info=“failed flags match” error=-13 profile=“lxd-cloud_</var/snap/lxd/common/lxd>” name=“/run/systemd/unit-root/bin/” pid=2027 comm=“(mysqld)” flags=“ro, remount, noatime, bind”

Redis-server (s-server…)
apparmor=“DENIED” operation=“mount” info=“failed flags match” error=-13 profile=“lxd-cloud_</var/snap/lxd/common/lxd>” name=“/run/systemd/unit-root/” pid=2308 comm=“(s-server)” flags=“ro, remount, noatime, bind”

I finally fixed it after adapting that solution for LXC, by setting security.nesting=true on my container.

But :

  1. What does security.nesting=true (I couldn’t find some documentation about it.)? Which security impact does it has?
  2. Is that the right solution for the AppArmor error I listed above?

Thank you for your help!

1 Like

No real security impact for unprivileged containers, rather disastrous security impacts for privileged containers (it allows bypassing apparmor and accessing /proc and /sys in unsafe ways).

It’s not a real solution but it’s a working solution. The real solution would be to have apparmor’s parser not be horribly broken when it comes to mount handling… we’ve been reporting issues upstream for a number of years (look for mount in their bug tracker), a bunch of those are effectively security issues (some are private because of that). We wish the apparmor project would dedicate more time to fixing those, extending the mount handling and more actively test this feature, but there’s only so much that as users, we can do.

1 Like

Thanks a lot (my CT is unprivileged).
Would you have some doc or some link about what secruity.nesting does/brings ?

Nope, other than it’s standing description that it allows for nested containers like running LXC, LXD or Docker inside a LXD container.

Interesting…
Can I add security.nesting true and lxc config set net-01 security.privileged true to the profile?
How to do it? just add these strings to file under the section config:?

just use lxc
lxc config set {container-name} security.nesting true

or
lxc config edit {container-name}
and add:
config:
++ security.nesting: “true”

Hello Stéphane,

I found this old thread when I was searching and want to learn more about LXC’s
“security.nesting=true” and “security.privileged=true”. I understand that nesting allows docker inside a lxc-container and privilged means “running as the same root” as the root on the host. Is that correct?

Can you maybe explain more? What is the difference of running a container with this both “options” versus “a real VM”? Can that be compared? - apart of ‘not running an own kernel’ like with a VM? Thank you for more ‘light’ on my questions.

Correct, we strongly recommend against using security.privileged=true

A VM gets you an environment like security.privileged but without the security concerns that come from a privileged container. However that also comes with all of the downsides of VMs, much higher CPU/RAM overhead, more difficult to share devices and storage, …

1 Like