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

[intrigeri]

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