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