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

[John Johansen]

On 1/27/24 01:21, Salvatore Bonaccorso wrote:
> Hi John,
> 
> On Sun, Dec 31, 2023 at 04:24:47AM +0000, Mathias Gibbens wrote:
>> 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.
> 
> Do you had a chance to look at this for 6.1.y upstream?
> 
> Asking/Poking since the point release dates are now clear:
> 
> https://lists.debian.org/debian-security/2024/01/msg00005.html
> 
> if possible I would like to include those fixes, but only if they are
> at least queued fror 6.1.y itself to not diverge from upstream.
> 
> Otherwise we will wait another round, but which means usually 2 months
> for the point release cadence.
> 
I am looking at it right now, I should be done with it today