Hello Carsten, On 12/12/17 21:38, Carsten Schoenert wrote: >>> 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 >
What I meant is: as soon as the package gets updated again by the Debian Security Team, the AppArmor profile gets disabled again. Do you mean I have to keep watching security updates closely and run the formentionned hack on my 100+ affected hosts each time it needs to ? I'm sorry,m but this is not acceptable for entreprise system admnistration. >> 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. Well, this change did end up being pulled in by the Security Team. We enterprise sysadmins who stick to OldStable or Stable until we have carefully tested a new release before deploying it to several hundreds hosts were grown to be used to the fact that OldStable or Stable could be trusted. With the issue at hand (or others like: "chromium is no longer supported in OldStable" [sic]), there is a serious dent in that trust. >> 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. As said, AppArmor can not be reliably re-enabled (without very dirty hacks monitoring the /etc/apparmor.d/disable symlinks does not re-appear). Please do consider changing your approach. If the debconf way is too complicated and you deem your AppArmor profile that broken, then another solution would be: 1. do NOT supply the profile in /etc/apparmor.d 2. provide a sample profile in /usr/share/doc/thunderbird/apparmor (along with a nice README) for those who know what they're up to Again, not being abale to re-enable AppArmor *reliably* (without dirty quirks) is really problematic for me. Thanks for considering again, Best, Cédric
