Hi, On Wed, May 24, 2023 at 11:22:29AM +0200, intrigeri wrote: > Hi, > > Salvatore Bonaccorso (2019-06-04): > > The following vulnerability was published for apparmor. This is > > already siscussed in the upstream bug, so this bug is really to track > > the 'downstream' status for us in the Debian BTS. Would technically > > not be needed but opted to fill a bug still in the Debian BTS for it. > > intrigeri has already explained the siutation in the upstream bug. > > > > CVE-2016-1585[0]: > > | In all versions of AppArmor mount rules are accidentally widened when > > | compiled. > > Upstream has fixed this:
Great :) > - 2.13.x (Bullseye): > https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_2.13.8 > > I propose we don't fix this in Bullseye: my rationale for treating > this as unimportant still applies, and with Bullseye released > 2 years ago, I'd rather not take the risk of breaking anything > there to fix a not-so-important issue. Agreed, we have marked the whole issue as unimportant so far, so I won't touch bullseye. > > - 3.0.y (Bookworm): > https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0.10 > > I'd like to cherry-pick the fix to Bookworm, either via a security > upload or a point-release, at some point in 2023 Q3: given Bookworm > will still be brand new and users' expectations have not been set > in stone yet, IMO the benefits of fixing this bug, and thus having > mount rules behave as documented, outweighs the minimal risk. That sounds good. Only question is if you want to fix it in bookworm from the start, and ask now for a unblock request (last chance for unblock requests filling re on 28th). But I can immagine it is more sensible to have first the fix exposed in trixie for a while, then backport it to bookworm. That said, fixing it in a bookworm point release would be enough and does not require a DSA. > I would welcome feedback on these 2 proposals, in particular from > security team members :) Hope the above input helps! Regards, Salvatore
