Network doesn't work w/o `lxc.apparmor.profile = unconfined` in unprivileged containers

[x-yuri (Yuri Kanivetsky)]

I don’t know much about apparmor, but is this by design? It doesn’t sound secure. Is this still more secure than privileged containers?

[tomp (Thomas Parrott)]

See:

Problem with disable apparmor for single container

lxc.apparmor.profile=unconfined makes your container run without apparmor confinement, that doesn’t however mean that profiles cannot be loaded and used by it nor that existing apparmor profiles on the host cannot apply to it. That’s why that option is so terrible, it effectively allows the host to mess with apparmor profiles on the host and any host apparmor profile to randomly apply to container processes.

and:

Problem with disable apparmor for single container

You should stay away from the lxc.apparmor.profile=unconfined and instead use raw.apparmor to allow anything which gets blocked by the stock profile.

[x-yuri (Yuri Kanivetsky)]

Thanks for the links. They address my question to a degree. But how do I allow network to work with the stock profiles? Well, probably by means of lxc.apparmor.raw. But maybe you can give any specific suggestions. It (network) seems like a common need. Which makes me think that I’m doing something wrong. Otherwise there should be probably some stock profile that allows it.

[tomp (Thomas Parrott)]

You shouldn’t need it to get networking working.

Please describe in more detail the problem you are having.

[x-yuri (Yuri Kanivetsky)]

Nothing much. Trying to launch a container. W/o lxc.apparmor.profile = unconfined it doesn’t work. The container doesn’t get an IP address (the journal).

It probably makes sense to add lxc.mount.auto = sys:ro to make the journal cleaner. Or even lxc.mount.auto = proc:mixed sys:ro cgroup:mixed as the Debian README suggests. Although I’m not sure what it affects. By the way they basically suggest unconfined.

[x-yuri (Yuri Kanivetsky)]

Oh, I see it’s something Debian specific. On an Ubuntu Jammy host, networking is working in an Ubuntu Jammy container, but doesn’t work in a Debian Bullseye container. Is the reason known?

Apparently systemd-networkd doesn’t start:

Oct 21 08:03:57 c systemd[1]: Starting Network Service...
Oct 21 08:03:57 c systemd[151]: systemd-networkd.service: Failed to set up mount namespacing: Permission denied
Oct 21 08:03:57 c systemd[151]: systemd-networkd.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-networkd: Permission denied
Oct 21 08:03:57 c systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=226/NAMESPACE
Oct 21 08:03:57 c systemd[1]: systemd-networkd.service: Failed with result 'exit-code'.
Oct 21 08:03:57 c systemd[1]: Failed to start Network Service.
Oct 21 08:03:57 c systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 1.
Oct 21 08:03:57 c systemd[1]: Stopped Network Service.

The following topic looks a bit similar. Debian Bullseye runs systemd-247.

Submitted an issue, because it looks like a bug.