Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
Ben Hutchings: > Yes, I now understand this. I'll add a Recommends: apparmor for the > next upload so this broken configuration is less likely to occur. Thanks! Cheers, -- intrigeri
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
On Sun, 2017-11-05 at 12:21 +0100, intrigeri wrote: > Hi, > > Ben Hutchings: > > My understanding was that enabling AppArmor shouldn't do very much > > until a policy is loaded (which it won't be if you don't install the > > userland tools). As you've found, that isn't entirely correct. > > Let me clear a potential misunderstanding: > > - It *is* correct that the AppArmor LSM doesn't do very much if no >policy is loaded, i.e. if the apparmor package is not installed. > > - The only report I've heard of so far of breakage caused by AppArmor >being enabled in the kernel by default, on systems that have no >AppArmor policy loaded, is #880490. That bug was not about AppArmor >denying anything, but about systemd trying to switch to an AppArmor >profile that was not loaded (precisely because the apparmor package >was not installed). Thankfully that bug has been fixed very >quickly. According to codesearch.debian.net it was the only >instance of this problem. I'm sorry I didn't think of this corner >case initially. > > > Still, I'll bump this back to serious as I don't think we should let > > this into testing yet. > > I think this does not apply anymore, now that the "unrelated" breakage > has been fixed, and the reasons behind it clarified. What do > you think? Yes, I now understand this. I'll add a Recommends: apparmor for the next upload so this broken configuration is less likely to occur. The current unstable version FTBFS on several architectures, so it wouldn't have gone into testing anyway. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
Hi, Ben Hutchings: > My understanding was that enabling AppArmor shouldn't do very much > until a policy is loaded (which it won't be if you don't install the > userland tools). As you've found, that isn't entirely correct. Let me clear a potential misunderstanding: - It *is* correct that the AppArmor LSM doesn't do very much if no policy is loaded, i.e. if the apparmor package is not installed. - The only report I've heard of so far of breakage caused by AppArmor being enabled in the kernel by default, on systems that have no AppArmor policy loaded, is #880490. That bug was not about AppArmor denying anything, but about systemd trying to switch to an AppArmor profile that was not loaded (precisely because the apparmor package was not installed). Thankfully that bug has been fixed very quickly. According to codesearch.debian.net it was the only instance of this problem. I'm sorry I didn't think of this corner case initially. > Still, I'll bump this back to serious as I don't think we should let > this into testing yet. I think this does not apply anymore, now that the "unrelated" breakage has been fixed, and the reasons behind it clarified. What do you think? Cheers, -- intrigeri
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
Control: tag -1 serious On Tue, 2017-10-31 at 17:21 +, Ben Hutchings wrote: > On Tue, 2017-10-31 at 17:10 +0100, Christoph Anton Mitterer wrote: > > The severity would have shown people which haven't upgraded, that there > > are issues... :-( > > > > > > On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote: > > [...] > > > Applications built for Linux are unrelated to Linux? I don't think > > > so. > > > > With that argument, one everything would be related on the kernel... > > and on the bootloader (cause without it, not applications at all)... > > and so on. > > [...] > > But without that argument, any regression in a kernel that breaks an > appplication is RC! I doubt we could ever release Debian with a kernel > included if we followed your reasoning. Still, I'll bump this back to serious as I don't think we should let this into testing yet. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
On Tue, 2017-10-31 at 17:10 +0100, Christoph Anton Mitterer wrote: > The severity would have shown people which haven't upgraded, that there > are issues... :-( > > > On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote: [...] > > Applications built for Linux are unrelated to Linux? I don't think > > so. > > With that argument, one everything would be related on the kernel... > and on the bootloader (cause without it, not applications at all)... > and so on. [...] But without that argument, any regression in a kernel that breaks an appplication is RC! I doubt we could ever release Debian with a kernel included if we followed your reasoning. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
The severity would have shown people which haven't upgraded, that there are issues... :-( On Tue, 2017-10-31 at 16:01 +, Ben Hutchings wrote: > Although you can disable it (security=dac or apparmor=0) if you want. Sure. I never said this wasn't possible. > > While I'm usually in favour of anything that improves security > > (leaving aside the question here whether SELinux wouldn't be the > > much > > more powerful solution ;-) )... this happened too silent (e.g. no > > NEWS entry)... peopl may not even have installed the userland > > tools. > > The change was noted in the changelog, so it's not silent. Well one cannot expect the average user to read every single entry of the kernel changes included in there, can one? > I intend to add a NEWS entry in the next linux-latest upload. It > doesn't make sense to add NEWS to linux-image-* packages as that will > only be displayed for upgrades that don't involve an ABI bump Perhaps one should have delayed the activation then until such bump, in which the user will get an update for the meta-package as well.. which then contains such notice :-) > My understanding was that enabling AppArmor shouldn't do very much > until a policy is loaded (which it won't be if you don't install the > userland tools). As you've found, that isn't entirely correct. Mhh well that was a surprise for me as well :) > Applications built for Linux are unrelated to Linux? I don't think > so. With that argument, one everything would be related on the kernel... and on the bootloader (cause without it, not applications at all)... and so on. smime.p7s Description: S/MIME cryptographic signature
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
Control: severity -1 important Control: affects -1 tor On Tue, 2017-10-31 at 16:07 +0100, Christoph Anton Mitterer wrote: > Package: src:linux > Version: 4.13.10-1 > Severity: critical > Justification: breaks unrelated software > > Apparently AppArmor was enabled per default in the last version. Although you can disable it (security=dac or apparmor=0) if you want. > While I'm usually in favour of anything that improves security > (leaving aside the question here whether SELinux wouldn't be the much > more powerful solution ;-) )... this happened too silent (e.g. no > NEWS entry)... peopl may not even have installed the userland tools. The change was noted in the changelog, so it's not silent. I intend to add a NEWS entry in the next linux-latest upload. It doesn't make sense to add NEWS to linux-image-* packages as that will only be displayed for upgrades that don't involve an ABI bump My understanding was that enabling AppArmor shouldn't do very much until a policy is loaded (which it won't be if you don't install the userland tools). As you've found, that isn't entirely correct. > Also it breaks unrelated software, e.g. tor no longer starts and some > more as well. Applications built for Linux are unrelated to Linux? I don't think so. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs
Package: src:linux Version: 4.13.10-1 Severity: critical Justification: breaks unrelated software Hi. Apparently AppArmor was enabled per default in the last version. While I'm usually in favour of anything that improves security (leaving aside the question here whether SELinux wouldn't be the much more powerful solution ;-) )... this happened too silent (e.g. no NEWS entry)... peopl may not even have installed the userland tools. Also it breaks unrelated software, e.g. tor no longer starts and some more as well. Cheers, Chris.
