[apparmor] RFC: handling xdg-open and similar helpers

[John Johansen]

On 01/25/2018 12:46 PM, Simon McVittie wrote:
> On Thu, 25 Jan 2018 at 11:29:26 -0800, John Johansen wrote:
>> On 01/25/2018 10:15 AM, Vincas Dargis wrote:
>>> Even if environment scrubbing would work, should it still allow execute xdg-open _anything_ (like that example) directly?
>>
>> it would depend on how you structure your policy, you certainly don't have to allow it
> 
> I can't help thinking that, when D-Bus mediation goes upstream, launching
> URLs/files via D-Bus activation (rather than by executing xdg-open and
> having it execute some other program) goes a long way towards fixing this.
> 

yes that will help, but unfortunate that won't likely land until 4.17
with the way things have gone late (I was targeting 4.15 but the
revert has delayed us a bit more than cycle).

> Having a less-privileged program execute a more-privileged program
> as a child is always rather scary: a lot of the execution environment
> (environment, rlimits, ...) is under the control of the parent. If the
> more-privileged program is actually run by a trusted platform service
> (like the OpenURI and Email portals in xdg-desktop-portal, as used
> by Flatpak; or systemd --user; or dbus-daemon) as a result of an IPC
> request, and gets the request from the less-privileged program via IPC,
> then that's immediately a lot less alarming.
> 
>>>>> Dragon only needs to open browser (for clicking "Help -> Report
>>>>> a bug") and email client (when clicking translator's email button in
>>>>> About dialog), and that's it.
> 
> Sending D-Bus messages to the OpenURI and Email portals, or something
> very similar, would certainly be enough for this. If Dragon (whatever
> Dragon is :-) was allowed to send D-Bus messages to the OpenURI portal
> but nowhere else, then it could open URIs and an email composer,
> but nothing else.
> 
>     smcv
>