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