[Webkit-unassigned] [Bug 188568] [GTK][WPE] Implement subprocess sandboxing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188568

--- Comment #36 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Patrick Griffis from comment #33)
> We just don't use any system services atm.

Let's not leave the #if 0 code then, but add a comment explaining how to add the system proxy if needed in the future.

> > > Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:285
> > > +        GUniquePtr<char> dconfConfigDir(g_build_filename(configDir, "dconf", nullptr));
> > > +        bindIfExists(args, dconfConfigDir.get(), BindFlags::ReadWrite);
> > 
> > Hmm, I think you're right that this is too big a hole... please add a FIXME
> > here. I don't remember exactly what we discussed previously, but we should
> > try to find some way to put dconf into a read-only mode so that our
> > subprocesses have access to the settings but can't write them. I assume you
> > already tried binding read-only and it didn't work?
> > 
> > (dconf just gained a maintainer, btw, so we should be able to change it if
> > need be.)
> 
> Upstream DConf already planned on working on this but I don't think its far
> along (no idea if I could help). I didn't actually test making it read-only
> but I just imagined that doesn't matter when you can talk to the DBus
> service.
> 
> I briefly discussed this with mclasen and it seems like a portal to access
> Gtk Settings would be accepted. I'll let you decide if thats worth working
> on. (That also means we would depend on xdg-desktop-portal.)

I think it would fall within the scope of this project, since we really don't want to allow write access to dconf.

I don't think it's the highest-priority until functionality regressions are addressed. E.g. credentials access for HTTP auth is still an issue. And drag-and-drop.

> > > Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:459
> > > +    // FIXME: There is an env var for this too (and should we allow its dbus access?)
> > 
> > Yeah we should allow D-Bus access. I think codec installation is broken
> > currently anyway, though, so I'm OK with leaving that as a FIXME.
> > 
> 
> Added permissions. It works fine when tested manually (and back when I tried
> MiniBrowser) but
> not within Epiphany so I think the bug is there.

Epiphany doesn't have any support for missing codecs installation. I have a WIP patch in https://gitlab.gnome.org/GNOME/epiphany/commit/7a5e7f98a18e605c20f8b0333d753c3a66495329. At the time I was working on that, it was broken due to bug #147822 (see comment 3 there), so there was no point in adding the code to Epiphany. It's possible something has changed in the past two years, but I'm not sure what it would have been since we really had no idea how to make it work as desired.

(In reply to Patrick Griffis from comment #35) 
> Hmm, The DBusProxy isn't behaving as expected atm so I just want to say
> please don't merge this too hastily before I give the OK.

When you are ready for it to be committed, you'll need to set the cq? Bugzilla flag, then I can change it to cq+ to trigger the commit. You'll also need to use the r? flag to request review.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180903/a608e886/attachment-0001.html>