2017.03.20 11:23, intrigeri rašė:
Last time I checked, they did include it just like we already do, via /usr/share/doc/apparmor-profiles/extras/usr.lib.firefox.firefox in the apparmor-profiles package. But I didn't check recently so they might very well be shipping another profile in their firefox package nowadays.
Yes, they have profile in firefox package [0]. I'm using it in my Kubuntu 16.04 desktop, though with some modifications if I recall correctly...
1. Find out which profile (if there are several, e.g. a non-upstream one shipped in Ubuntu's firefox package) is the best one, in terms of safety/usability trade-offs and maintenance level.
I guess we could try Ubuntu Firefox profile, it is more advanced compared to profiles/apparmor/profiles/extras/usr.lib.firefox.firefox in AppArmor source.
3. If it's good enough, consider having apparmor-profiles ship it (disabled by default) in /etc/apparmor.d/ instead of /usr/share/doc/apparmor-profiles/extras/, to improve the UX of enabling it and keeping it up-to-date wrt. upstream changes.
But should that profile be a base of Ubuntu Firefox profile (for example) with ./debian/patches on top? Or "fixed" old "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox", by sending patches upstream? Or brand-new Debian-only "profiles/apparmor.d/usr.lib.firefox.firefox" that is missing in AppArmor upstream? Or something else?
5. Consider enforcing the profile by default: can we do it? is it blocked by something else, like proper desktop notifications offering guidance whenever the AppArmor confinement blocks something?
There is that apparmor-notify, though I haven't tried it myself. I just use aa-logprof regularly. I would really like AppArmor to be more mainstream'ish... If app could maybe get some kind of feedback directly and inform user that it could not save that .PDF into ~/ because AppArmor profile denied it, so could you try another directory instead of just disabling AppAmrmor completely :-) , please? Maybe if AppArmor profile had sort of tags or hints, specifying that this "somepath/** rwk" rule is designed to be user-accesible downloaded/generated content directory so user should really use that, hinted then by the app itself (with help of libapparmor or whatever). Anyway, these dreams are out of this bug scope I guess. [0] https://bazaar.launchpad.net/~mozillateam/firefox/firefox.xenial/view/head:/debian/usr.bin.firefox.apparmor.14.10
