Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[Mathias Gibbens]

On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> John, did you had a chance to work on this backport for 6.1.y stable
> upstream so we could pick it downstream in Debian in one of the next
> stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> mediating locking non-fs unix sockets") does not work, if not
> havinging the work around e2967ede2297 ("apparmor: compute policydb
> permission on profile load") AFAICS, so that needs a 6.1.y specific
> backport submitted to stable at vger.kernel.org ?
> 
> I think we could have people from this bug as well providing a
> Tested-by when necessary. I'm not feeling confident enough to be able
> to provide myself such a patch to sent to stable (and you only giving
> an Acked-by/Reviewed-by), so if you can help out here with your
> upstream hat on that would be more than appreciated and welcome :)
> 
> Thanks a lot for your work!

  I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.

  I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.

  With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.

  While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.

Mathias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rebase-01-e2967ed.patch
Type: text/x-patch
Size: 13454 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20231231/1364ba9f/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rebase-02-1cf26c3.patch
Type: text/x-patch
Size: 2178 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20231231/1364ba9f/attachment-0003.bin>
-------------- 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/20231231/1364ba9f/attachment-0001.sig>