Bug#858174: Please provide an AppArmor profile for Firefox
intrigeri writes: > In any case, they don't enforce the profile by default, according to > https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles If I read that page correctly, Ubuntu enables the profile for Firefox by default in 20.04 LTS (released on April 23, 2020) and in 20.10.
Bug#858174: Please provide an AppArmor profile for Firefox
On 2018-10-30 20:59, intrigeri wrote: Vincas Dargis: intrigeri, what is rationale for upping it to "normal"? What do you mean? Today I merely tagged this bug "upstream". Oh, sorry, right, it was changed from wishlist to normal in "Sun, 29 Oct 2017 11:21:06 GMT". I erroneously joined it with latest notification.
Bug#858174: Please provide an AppArmor profile for Firefox
Vincas Dargis: > intrigeri, what is rationale for upping it to "normal"? What do you mean? Today I merely tagged this bug "upstream". > Maybe you would like/expect to have it in Buster? Absolutely not. > I kinda feel if we can't make Thunderbird profile actually useful, > it's kinda naive to want Firefox too (though I would still want it, > naively :) ). We're exactly on the same page :) Cheers, -- intrigeri
Bug#858174: Please provide an AppArmor profile for Firefox
intrigeri, what is rationale for upping it to "normal"? Maybe you would like/expect to have it in Buster? Maybe some one plans to upstream Ubuntu profile, etc. :) I would really like to have it, but looking at Thunderbird experience, we kinda lack abstractions for launching almost arbitrary application for downloads (as in Thunderbird attachments case), we don't have better alternative to using sanitized_helper (like `Px | Cx -> sanitized_helper` or smth.), profile will produce bunch of File Dialog-related denies too wile browsing directories, etc, etc. I kinda feel if we can't make Thunderbird profile actually useful, it's kinda naive to want Firefox too (though I would still want it, naively :) ).
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
Bug#858174: Please provide an AppArmor profile for Firefox
Hi!
First, thanks a lot for moving this topic forward! It would be awesome
if Debian users could benefit, in a more straightforward manner, from
AppArmor confinement for Firefox :)
Ulrike Uhlig:
> @intrigeri: I was not aware that this profile is considered incomplete.
AFAIK it's incomplete, and there's no hope this will ever change,
because there's simply no way to maintain a general purpose AppArmor
profile for Firefox that can at the same time be restrictive enough to
be useful at all (in terms of security), but open enough to avoid
breaking random use cases (e.g. add-ons).
Now, of course a profile being incomplete doesn't mean it's useless :)
It just implies that one must be extra careful when considering
shipping said profile in enforce mode by default, especially when the
profile confines a high-profile piece of software like Firefox.
> Ubuntu ships it in Firefox as it seems. Or did I misunderstand that?
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.
In any case, they don't enforce the profile by default, according to
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles. …
which seems like the reasonable thing to do considering what I wrote
above about incompleteness :) But of course, that wiki page might be
outdated, and one may want to double-check.
>> If it needs update, this should happen there.
> The ultimate aim for AppArmor in Debian is to have each package install
> their own profile an make the apparmor-profiles and
> apparmor-profiles-extra package disappear on the long term.
Err, wait: yes and no. This is correct for apparmor-profiles-extra,
but *not* for apparmor-profiles. The former is indeed meant to be
temporary, while the latter contains profiles shipped in the upstream
AppArmor tarball, and I'm not aware of any plan to move them
anywhere else.
IMO the next steps on this front are:
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.
2. Test it with all popular Debian-packaged extensions enabled, on the
major desktop environments the Debian Installer offers (MIME
filetype associations may result in different programs being used
to open downloaded files).
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.
4. Encourage users to enforce the profile, gather user feedback and
improve it if needed.
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?
6. Later on, *if* the churn caused by having to upload src:apparmor
for every needed change in the profile is too big, consider moving
it to src:firefox{,-esr}. I'm especially thinking of
stable/security updates: new major ESR bumps might require AppArmor
policy updates, and then it would feel a bit overkill to have to
upload src:apparmor to stable/security in lock step, in order to
avoid breaking Firefox in Debian for AppArmor users. And then,
if/once we ever reach this point, then we will definitely need to
have this conversation with Mike :)
If you already went through some of these steps: great! (and sorry,
I didn't read the entire bug history)
Ideally, steps 1-4 would be done early in the Buster cycle, so that we
have enough data later in that cycle to do step 5 and evaluate whether
the problem described at step 6 will happen.
Thoughts?
Cheers!
--
intrigeri
Bug#858174: Please provide an AppArmor profile for Firefox
Hi Mike, Mike Hommey: > control: reassign -1 apparmor-profiles >> Package: firefox >> Severity: normal >> as you might know, AppArmor confines programs according to a set of >> rules that specify what files a given program can access. This approach >> helps protect the system against both known and unknown vulnerabilities. >> In several distributions such as Ubuntu or Tails, AppArmor is enabled by >> default. > > AppArmor profiles ought to be in the apparmor-profiles package. In fact, > there is one for Firefox there according to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805594#24 @intrigeri: I was not aware that this profile is considered incomplete. Ubuntu ships it in Firefox as it seems. Or did I misunderstand that? > If it needs update, this should happen there. The ultimate aim for AppArmor in Debian is to have each package install their own profile an make the apparmor-profiles and apparmor-profiles-extra package disappear on the long term. Cheers! u.
Bug#858174: Please provide an AppArmor profile for Firefox
control: reassign -1 apparmor-profiles On Sun, Mar 19, 2017 at 11:44:00AM +, Ulrike Uhlig wrote: > > > Package: firefox > Severity: normal > > Hi, > > as you might know, AppArmor confines programs according to a set of > rules that specify what files a given program can access. This approach > helps protect the system against both known and unknown vulnerabilities. > In several distributions such as Ubuntu or Tails, AppArmor is enabled by > default. AppArmor profiles ought to be in the apparmor-profiles package. In fact, there is one for Firefox there according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805594#24 If it needs update, this should happen there. Mike
Bug#858174: Please provide an AppArmor profile for Firefox
Package: firefox Severity: normal Hi, as you might know, AppArmor confines programs according to a set of rules that specify what files a given program can access. This approach helps protect the system against both known and unknown vulnerabilities. In several distributions such as Ubuntu or Tails, AppArmor is enabled by default. I've not been able to find such a profile in the current Firefox package. There is an AppArmor profile for Firefox available upstream: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/firefox/vivid/view/head:/debian/usr.bin.firefox.apparmor.10.04 (this is the upstream profile which has been integrated into Ubuntu's packaging of Firefox). This profile is only active if people have installed AppArmor in first case, so it should never break the package for users without AppArmor. The profile can be included in your packaging quite easily. All the necessary steps are documented here: https://wiki.debian.org/AppArmor/Contribute/FirstTimeProfileImport Please also see examples in the packages torbrowser-launcher or in Icedove (https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/tree/debian). Please let me know if you need help. Cheers! ulrike
