[pkg-apparmor] Bug#858174: Please provide an AppArmor profile for Firefox

[intrigeri]

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