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 :) .
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
