Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox
2017.04.05 09:08, intrigeri rašė: IMO the parts that require third-party kernel patches shall be upstreamed as well: the end goal would be that the resulting upstream profile can be pulled as-is by as many distros as possible, including those that apply these patches, i.e. Ubuntu and OpenSUSE. Right, agreed, silly me.
Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox
Hi, Vincas Dargis: > 2017.04.04 08:26, intrigeri rašė: >> Thanks! But it ships disabled (or in complain mode) by default, right? > Yes it's disabled, and it's from firefox package. Thanks! >> OK. So these improvements shall be upstreamed. >>> Or "fixed" old "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox", >>> by sending patches upstream? >> >> Yes, please. And as written above, this doesn't prevent us from >> shipping it to /etc/apparmor.d (disabled by default) if it's >> good enough. > OK but I am still a little puzzled. If Ubuntu Firefox team > does not upstream their profile it (because it's too Ubuntu-specific?), so it > kinda maybe means we can't use it as "fix" for old > "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox" directly, right? Right, that's why I wrote "So these improvements shall be upstreamed" :) > So we just take some interesting parts (like Elecrolysis a.k.a. e10e > support?), > ignore networking because Debian kernel does not has it, and... try to push > that > into AppArmor upsteam? IMO the parts that require third-party kernel patches shall be upstreamed as well: the end goal would be that the resulting upstream profile can be pulled as-is by as many distros as possible, including those that apply these patches, i.e. Ubuntu and OpenSUSE. Cheers, -- intrigeri
Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox
2017.04.04 08:26, intrigeri rašė: Thanks! But it ships disabled (or in complain mode) by default, right? Yes it's disabled, and it's from firefox package. Tested on clean Ubuntu 16.04 LTS and 17.04 daily build virtual machines (it's the same): $ file /etc/apparmor.d/disable/usr.bin.firefox /etc/apparmor.d/disable/usr.bin.firefox: symbolic link to /etc/apparmor.d/usr.bin.firefox $ dpkg -S /etc/apparmor.d/usr.bin.firefox firefox: /etc/apparmor.d/usr.bin.firefox Profile itself does not declare a complain mode. OK. So these improvements shall be upstreamed. Or "fixed" old "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox", by sending patches upstream? Yes, please. And as written above, this doesn't prevent us from shipping it to /etc/apparmor.d (disabled by default) if it's good enough. OK but I am still a little puzzled. If Ubuntu Firefox team does not upstream their profile it (because it's too Ubuntu-specific?), so it kinda maybe means we can't use it as "fix" for old "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox" directly, right? So we just take some interesting parts (like Elecrolysis a.k.a. e10e support?), ignore networking because Debian kernel does not has it, and... try to push that into AppArmor upsteam? There is that apparmor-notify, though I haven't tried it myself. Sadly, it's poorly integrated in Debian currently, iirc because it relies on parsing logs instead of using the relevant audit interface. I'm pretty sure we have bugs about it in the Debian and upstream bug tracking systems. Indeed. There's some work going on upstream about these topics, feel free to start a discussion about it on the upstream AppArmor mailing list :) Oh well. I imagine it could be some sort of daemon with DBus interface to inform apps that are concerned about being confined :-) ? Anyway, yeah, that's upstream discussion. At least we could do is to upstream this line uncommented (as in Ubuntu Firefox profile): ## include so if we will be targeting to make Firefox enabled & enforced by default, this would allow users to add local changed without modifying profile itself, avoiding merges on upgrades, making some less pain.
Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox
Hi, Vincas Dargis: > 2017.03.20 11:23, intrigeri rašė: > Yes, they have profile in firefox package [0]. Thanks! But it ships disabled (or in complain mode) by default, right? >> 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. OK. So these improvements shall be upstreamed. We already had to deal with a situation when we shipped a profile from Ubuntu (Chromium) that was substantially different from upstream's, and it was a pain to maintain our own delta on top. >> 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? No, please. > Or "fixed" old "profiles/apparmor/profiles/extras/usr.lib.firefox.firefox", > by sending patches upstream? Yes, please. And as written above, this doesn't prevent us from shipping it to /etc/apparmor.d (disabled by default) if it's good enough. >> 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. Sadly, it's poorly integrated in Debian currently, iirc because it relies on parsing logs instead of using the relevant audit interface. I'm pretty sure we have bugs about it in the Debian and upstream bug tracking systems. > 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. Indeed. There's some work going on upstream about these topics, feel free to start a discussion about it on the upstream AppArmor mailing list :) Cheers, -- intrigeri
Bug#858174: Re: Bug#858174: Please provide an AppArmor profile for Firefox
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
