Hello, > 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. Worse, this change affects even Jessie/OldStable, where AppArmor is silently disabled without sysadmin knowledge (I stumbled on this by mere chance). 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... 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). As a solution to the issue at hand, I would suggest: - use debconf to prompt the user for AppArmor enable/disable - default to enable, since it is what makes sense if the apparmor package is installed and kernel-enabled (security=apparmor) - do the /etc/apparmor.d/disable symlink magic in postinst, based on the debconf choice I hope this can be corrected back to Jessie, since this is serious security issue for those who enabled AppArmor knowingly. Thanks and best, Cédric -- Cédric Dufour @ Idiap Research Institute
