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

[Vincas Dargis]

On 1/26/18 10:06 AM, intrigeri wrote:
> 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.
> 
> +1
> 
>> 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).
> 
> Frankly, as much as I would love to eventually be able to use this in
> policy on Debian & Tails, I'm not worried about a 4 months delay on
> this front. Not only we've already been waiting for it for so long
> that a few months more doesn't make a big difference, but it's only
> one piece of the bigger picture: quite some work is needed elsewhere
> to fully take advantage of this new kernel mediation feature.

This all IPC thing looks really uplifting... but it feels like it's for a far, far future...

I mean, GUI apps comes from various frameworks and "families", and while I do imagine that Gnome & KDE apps might see 
this execution-via-IPC thing adopted (relatively) fast (have it Totem or Dragon media players as example), though other 
"stand alone" applications (Mozilla stuff, Calibre, qBitTorrent, all the Java / Mono world, etc...) would probably need 
individual poking with bug reports and patches.

I don't imagine "everyone" mass-migrating into Flatpacks/Snaps too...

> One could push forward the corresponding changes needed in the
> surrounding applications & platform ecosystem without waiting for
> fine-grained D-Bus mediation to land in Linux mainline: at first
> glance, that means picking a few first candidate user stories we want
> to confine better (e.g. opening URLs from Evince or opening an
> attachment from Thunderbird), decide how ideally we would like them to
> ask $more_privileged_program to do $stuff, and make it happen.

So there's architectural decisions to be made about that `$more_privileged_program->$stuff()`, that would be acceptable 
for Mozilla and GNOME and KDE and rest of the "app world". Well, Simon mentioned these portals, maybe it's that, maybe not.

> FYI I'm not going to work on this personally during the current Debian
> development cycle, but one of my goals for the next one (Bullseye)
> will probably be to help fix the desktop app confinement story we
> offer on the Debian desktop. It's not clear to me yet how much it will
> involve AppArmor but regardless of the exact sandboxing technology
> that's used to confine the app, in any case we need to teach the apps
> (or some underlying toolkit) to send IPC requests instead of executing
> programs themselves.

For these who are advanced enough to manually install for example `apparmor-profiles-extra` with more enabled-by-default 
profiles, _with improved xdg-open-and-friends support_ :), with upcoming conditional includes for better customization 
and all else... I still feel this proposal would be useful in ~mid term, as I don't see xdg-open-and-friends moving away 
fast enough.

Though might be I'm too pessimistic or miss-informed in this topic, that could be true :) .