Hello Cédric, I lowered down the severity to wishlist, please see https://www.debian.org/Bugs/Developer#severities
On Tue, Dec 12, 2017 at 03:49:23PM +0100, Cédric Dufour - Idiap Research Institute wrote: > Package: thunderbird > Version: 1:52.5.0-1~deb8u1 > severity: grave > > As stated as comment to the bug corresponding to the source of this > issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882672): > > > I think we can implement this change by shipping a symlink to the > > profile in /etc/apparmor.d/disable/. My understanding is that dpkg > > will treat this removal of a conffile as a change worth preserving on > > upgrades, i.e. it won't install the symlink again if it's > > been deleted. > > I deleted the symlink and 'apt-get reinstall thunderbird' and the > symlink is back, thus preventing re-activation of Thunderbird AppArmor > profile. No need for a reinstallation the package, just remove the symlink and let AppArmor parse the available profiles. $ sudo rm /etc/apparmor.d/disable/profile.name $ sudo apparmor_parser -r /etc/apparmor.d/profile.name > Worse, this change affects even Jessie/OldStable, where AppArmor is > silently disabled without sysadmin knowledge (I stumbled on this by > mere chance). We do not make changes between releases normaly, only for things that are really release depended like the GCC version. > This is very unfortunate, knowing my company relies on a carefully > tuned - and working! - AppArmor profile for Thunderbird, as an > important piece of its overall security setup. > And we're very happy with it preventing who-knows-which binary to open > who-knows-what-malware-ridden attachements! No longer now... Well, AppArmor wasn't included in the Stretch release as a release goal nor was it widely tested. And now it's has shown that the problems around the AppArmor profile has growing over and over so we decided to not bother people by things that are not working really well in recent AppArmor profiles for Thunderbird. The profile for LibreOffice is disabled since the beginning of the AppArmor in Debian. So no, we can't say we have had a god solution around AppArmor and Thunderbird. It's fine if the existing profile is working good enough on your side but the reality on most other user installation is showing some more problems. > I don't understand all the fuss about users complaining about AppArmor > profiles not working. AppArmor is about *mandatory* access control, > iow. explicitly specifying what actions are allowed. You can not > expect to use AppArmor for what is intended for and ask for it to be > OK with all possible use cases (in this latter case, you'd better not > use AppArmor to start with, since it ends up to be nothing but > security theater). Well, user expect usability and not to be treated in every corner by a system administrator by curtailing access to some resources. Take a look at recent created bug reports about mostly simple things that do not work with the current AppArmor profiles. > As a solution to the issue at hand, I would suggest: > - use debconf to prompt the user for AppArmor enable/disable The debconf mechanism is great for configuring basic *system* stuff but a golden rule is to not bother "normal" users with questions he can't really answer because they are simple users. So no, there will probably never a be a debconf setting here. > - default to enable, since it is what makes sense if the apparmor > package is installed and kernel-enabled (security=apparmor) That's the plan for the buster release, right now the current profile isn't robust enough for most of the use cases. The profile needs to be improved, there are no doubt about that. > - do the /etc/apparmor.d/disable symlink magic in postinst, based on > the debconf choice That would require the existence if a debconf setup, that will not happen as written above. > I hope this can be corrected back to Jessie, since this is serious > security issue for those who enabled AppArmor knowingly. We wont change this behavior in the near future. > PS: I marked the severity as "grave" since it does "introduces a > security hole allowing access to the accounts of users who use the > package" for those who did rely on AppArmor to control Thunderbird > bevahior along attachements. No, the disabling of the AppArmor profile isn't introducing a security hole right now. Especially as the user or the administrator can easily turn it on again. Thunderbird isn't that insecure as before without AppArmor support. So feel free to re-enable AppArmor on your side, doing this by some automatic system like ansible, chef, puppet or $whatever makes this easy. If you can help to improve the existing profile then please do so. Regards Carsten
