Control: forwarded -1 https://bugs.launchpad.net/apparmor/+bug/1730220 Control: clone -1 -2 Control: retitle -2 thunderbird: apparmor should allow the execution of google-chrome-beta
Hi Philipp, first of all, thanks for your report; I particularly appreciate that you've put quite some thought into the problem and its various potential long-term solutions :) Philipp Kern: > I turned on AppArmor and Thunderbird stopped opening links for me. dmesg > has the following denial message: > [ 3795.153239] audit: type=1400 audit(1509283418.100:64): > apparmor="DENIED" operation="exec" profile="thunderbird" > name="/opt/google/chrome-beta/google-chrome-beta" pid=31896 > comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 I'm cloning a dedicated bug for this specific problem: it can trivially be fixed without blocking on a solution to the general one. > I think there needs to be some kind of defined way for browsers to be > allowed to be executed. I agree, see below. > Literally the only browser Thunderbird should be able to execute is the > one configured as the default, not some set of ancient and potentially > exploitable other browsers (like some compiled against old webkit > versions), looking at the current list in the abstraction. I agree this would be ideal but: - While dynamic generation of ad-hoc strict AppArmor profiles is doable for services that run as root (e.g. that's what libvirt does), I'm not aware of any existing solution for non-root apps, and it looks like it would require lots of work, so let's not count on it. - I think this is better solved by a broker design i.e. the sandboxed app asks some privileged helper, outside the sandbox, to open a URL. This is certainly doable with AppArmor (iirc Ubuntu Phone and snaps have something like this) but I doubt it'll be nicely integrated soon and it requires the app to cooperate so that's not something we'll get in Thunderbird on the short term (see Simon's post on debian-devel@ about how it can be done for modern GTK/Glib apps). - Arguably it's the distro's responsibility to avoid shipping/leaving exploitable browsers around on users' systems. > I suppose one way would be to always launch some kind of > sensible-browser binary and let that call out to the default browser > only. Indeed, if Thunderbird was using xdg-open, sensible-browsers and similar it would be much easier to come up with an AppArmor policy that's better both in terms of security and UX. When working on this 1-2 years ago Ulrike noticed this isn't the case. I haven't checked recently though. If we can't find a simpler solution I'm open to checking with Mozilla why they do it their way. > Another way would be to let browser packages ship a file that allows > their execution and then the installed ones are automatically available > to Thunderbird (or another browser-spawning program). In this case > Chrome would need to start shipping such a file. I think we can totaly do this: the #include directive can take a directory (e.g. something.d) as an argument so for example abstractions/ubuntu-browsers could include a .d directory where each browser (e.g. google-chrome-beta) could drop its snippet. Given the above, this is likely the only solution that would be flexible enough for your needs, while being doable on the short term without major changes. I've started a discussion about this upstream: https://bugs.launchpad.net/apparmor/+bug/1730220 Cheers, -- intrigeri
