Control: block 1038315 by -1 Control: block 1042880 by -1 I don't think we have a good understanding of the root cause of this issue. Initially we thought this was a known upstream issue with all- but very recent versions of apparmor and a corresponding lxc profile fix [0]. However, it appears this is a different issue that somehow depends on the interaction of bookworm's versions of the kernel, apparmor, and/or lxc.
A minimal reproducer is to install bookworm and create a container with a systemd service using a hardening option like PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the service will fail. But, grab a kernel from testing (6.4.11-1) and then things work -- with no other changes required. I tried the "oldest" kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the service works properly with that version as well. So, something changed in the kernel (either upstream or in Debian's packaging) between 6.1 and 6.3 that "unbreaks" services within lxc containers. Given that simply installing a newer kernel fixes things, I am hesitant to start making changes to lxc until we actually understand what's changed when running the newer kernel and how it's affecting lxc's behavior. On Thu, 2023-08-31 at 19:54 +0200, Christian Boltz wrote: > That said - the DENIED log entry translates to > > unix send type=dgram, > > You could try if adding this rule to the lxc-autopkgtest-lxc-iomhit_* > profile helps - but if the issue is really on the kernel side, my > hope is limited). I have tried tweaking the apparmor profile that's generated for containers (the relevant part is defined in the variable AA_PROFILE_UNIX_SOCKETS in src/lxc/lsm/apparmor.c), but haven't had any success in a workaround. I am not super familiar with apparmor, so maybe I'm not specifying things right, but I've previously tried the sort of rules Christian suggested, none of which have had any affect. On Fri, 2023-09-01 at 13:23 +0200, Michael Biebl wrote: > The only way to fix the container was to use the aforementioned > `lxc.apparmor.profile = unconfined`. > I think we should do that as the breakage is rather widespread and I > already see individual packages trying to work around that to at > least keep debci afloat. I strongly dislike the idea of blanketly disabling apparmor profiles by default for all lxc installs, since apparmor is one of the ways of helping to ensure isolation of containers. For the specific instance of debci, /etc/lxc/default.conf can be modified post-lxc install to change lxc.apparmor.profile from "generated" to "unconfined" for the time being. Mathias --- [0] -- https://github.com/lxc/lxc/issues/4333 [1] -- https://snapshot.debian.org/package/linux-signed-amd64/6.3.1%2B1~exp1/
signature.asc
Description: This is a digitally signed message part
