[apparmor] RFC: handling xdg-open and similar helpers
Simon McVittie
smcv at collabora.com
Thu Jan 25 20:46:30 UTC 2018
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.
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
More information about the AppArmor
mailing list