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

control: reassign -1 apparmor-profiles

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

Hi Mike,

Mike Hommey:

@intrigeri: I was not aware that this profile is considered incomplete.
Ubuntu ships it in Firefox as it seems. Or did I misunderstand that?

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.

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:

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.

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.

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!

2017.03.20 11:23, intrigeri rašė:

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...

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.

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?

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

Hi,

Vincas Dargis:

Thanks! But it ships disabled (or in complain mode) by default, right?

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.

No, please.

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.

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 :)

Cheers,

2017.04.04 08:26, intrigeri rašė:

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 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?
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 <local/usr.bin.firefox>
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.

Hi,

Vincas Dargis:

Thanks!

Right, that's why I wrote "So these improvements shall be upstreamed" :)

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,

2017.04.05 09:08, intrigeri rašė:

Right, agreed, silly me.

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 :) ).

Vincas Dargis:

What do you mean? Today I merely tagged this bug "upstream".

Absolutely not.

We're exactly on the same page :)

Cheers,

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.

intrigeri <intrigeri@debian.org> writes:

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.

So ubuntu has a similar profile in apparmor-profile.
https://packages.ubuntu.com/impish/all/apparmor-profiles/filelist

But there is another profile shipped with ubuntu's firefox package
which seems to be working better; /etc/apparmor.d/usr.bin.firefox.
https://packages.ubuntu.com/impish/all/firefox/filelist