Failed to query system properties: Access denied in Nested container

LXD
1

I have the following configuration:

  • c1 runs on LXD on bare metal with security.nesting=true
  • nested1 runs inside c1 
root@c1:~$ lxc --version
4.0.9

root@nested1:~$ hostnamectl
Failed to query system properties: Access denied

Is this expected? Am I missing some security switch in c1?

2

Any update on this?

3

Nested containers can hit issues with some services. In this case, it looks like it may be dbus/policykit being unhappy.

You can look at dmesg on the host to see if it’s apparmor blocking something.

4

Thanks.

I see the following deny event in the upmost host.

$ dmesg -wT
[mar may 31 22:19:35 2022] audit: type=1400 audit(1654028377.654:318): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 namespace="root//lxd-project_c1_<var-snap-lxd-common-lxd>" profile="lxd-c1_</var/snap/lxd/common/lxd>" name="/run/systemd/unit-root/proc/" pid=267216 comm="(d-logind)" fstype="proc" srcname="proc" flags="rw, nosuid, nodev, noexec"

If I set


$ lxc config set c1 raw.lxc "lxc.apparmor.profile=unconfined"

the deny event doesn’t show up, so it is something related to the apparmor profile. I’d expect that security.nesting should set up the apparmor profile so that these kinds of deny do not happen, do you have any advice on troubleshooting apparmor issues, in the context of LXD?

5

What image are you using for the nested container?

6

I tried with different images: ubuntu:22.04, debian/11 and observed the same behavior.

7 
Jun 01 21:23:13 u1 networkd-dispatcher[121]: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to query AppArmor policy: Permission denied

So this looks like it’s the dbus-daemon integration with apparmor which isn’t working as it should. I tried even putting a blanket rule to allow all dbus access but it’s not working.

I suspect the best option here is to file a bug against apparmor upstream to have someone familiar with their dbus integration take a look at what’s going on here.

As an ugly workaround, I’ve confirmed that editing /usr/share/dbus-1/system.conf and adding:

  <apparmor mode="disabled"/>

To the busconfig section, followed with a container reboot does in fact fix the issue.

1 Like
8

Could you file an issue here: https://gitlab.com/apparmor/apparmor/-/issues/new

9

Thanks!

Done:

10

Hello @stgraber,

I did as you suggested in both the nested and the host container but I get a different error now:

root@nexted:~# hostnamectl
Failed to connect to bus: Connection refused