Bug#1050256: autopkgtest fails on debci

[Mathias Gibbens]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230901/4de0a3d8/attachment.sig>