[Linux] SeccompFilters: improve the port-agnostic whitelist

• Component: WebKit2
• Status: RESOLVED FIXED

[Michael Catanzaro]

I think pretty much all the files and directories that the GTK+ port web process needs to access are generic enough that they should most likely be whitelisted for EFL as well. I'd like to add several locations to the web process whitelist:

* /lib64 and /usr/lib64: nothing has any chance of working on x86_64 Linux otherwise, except on Debian which doesn't have these directories.
* /run/user/UID where UID is the result of getuid(), since at-spi2 creates lots of random directories here. (I'd rather this be more restrictive.) I think at-spi2 is not specific to GTK+.
* Specific files in /sys/fs/cgroup, for the memory pressure handler that landed last month. (These accesses will fail regardless because those files are owned by root. Not sure how the memory pressure handler is supposed to work.)
* Check $XDG_DATA_HOME before assuming that mime types are in ~/.local/share/mime
* /var/tmp -- this is unfortunate, but with recent enough mesa (for DRI3) and barring a configure-time override (which Debian wisely does), shared memory winds up here: https://bugzilla.redhat.com/show_bug.cgi?id=1172869
* mesa configuration files
* Various directories needed by udev
* ~/nv for the NVIDIA proprietary driver, suggested by Zan.
* Tempted to also put gstreamer stuff here....

We can talk about whether any of these locations should be moved to the GTK+ and/or EFL whitelists instead.

[Michael Catanzaro]

(In reply to comment #0)
> * /var/tmp -- this is unfortunate, but with recent enough mesa (for DRI3)
> and barring a configure-time override (which Debian wisely does), shared
> memory winds up here: https://bugzilla.redhat.com/show_bug.cgi?id=1172869
> * mesa configuration files
> * Various directories needed by udev

I currently have access to these directories disabled if compiled without support for mesa, but I wonder if it's wiser to just unconditionally allow them to avoid potential future breakage.

[Michael Catanzaro]

Created attachment 243951 [details]
Patch

[Michael Catanzaro]

Created attachment 249298 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

[Michael Catanzaro]

Comment on attachment 249298 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

So, this is the first patch in my series. The goal here is the same as in bug #142987, but I've spent enough time rebasing this series already that I'd rather commit them separately, especially since that patch is the last in the series and this is the first, it would just be a pain. So this one alone doesn't really accomplish much (well, it makes accelerated compositing work), it's just a bit better than what we have now....

[Zan Dobersek]

Comment on attachment 249298 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

View in context: https://bugs.webkit.org/attachment.cgi?id=249298&action=review

> Source/WebKit2/Shared/linux/SeccompFilters/SyscallPolicy.cpp:194
> +    // Needed by at-spi2.
> +    addDirectoryPermission("/run/user/" + String::number(getuid()), ReadAndWrite);

Is this truly port-agnostic, or is it specific to GNOME/GTK?

> Source/WebKit2/Shared/linux/SeccompFilters/SyscallPolicy.cpp:216
> +    // Try removing this permission when we can rely on a newer libxshmfence.

Put a FIXME here.

[Michael Catanzaro]

(In reply to comment #5)
> Is this truly port-agnostic, or is it specific to GNOME/GTK?

It's used by both EFL and GTK. In general, I don't mind giving a few extra permissions even if they're not needed (e.g. I assume WPE may not use ATK) since if you don't use at-spi2 then it's pretty unlikely you'd put important data in a folder named at-spi2. However in this case it's actually bad, since at-spi2 is not in the name of the permission at all. /run/user/1000 is quite wide a permission. I'll create a new bug #143004 to narrow this permission.

> Put a FIXME here.

OK (although it's removed in one of the follow-up patches)

[Zan Dobersek]

(In reply to comment #6)
> (In reply to comment #5)
> > Is this truly port-agnostic, or is it specific to GNOME/GTK?
> 
> It's used by both EFL and GTK. In general, I don't mind giving a few extra
> permissions even if they're not needed (e.g. I assume WPE may not use ATK)
> since if you don't use at-spi2 then it's pretty unlikely you'd put important
> data in a folder named at-spi2. However in this case it's actually bad,
> since at-spi2 is not in the name of the permission at all. /run/user/1000 is
> quite wide a permission. I'll create a new bug #143004 to narrow this
> permission.
> 

Place a FIXME comment above this code, a note about the problem and link to the bug, and we can move forward with this.

[Michael Catanzaro]

Created attachment 249490 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

Added FIXMEs

[Michael Catanzaro]

Created attachment 249491 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

Actually added FIXMEs

[WebKit Commit Bot]

Comment on attachment 249491 [details]
[Linux] SeccompFilters: improve the port-agnostic whitelist

Clearing flags on attachment: 249491

Committed r182021: <http://trac.webkit.org/changeset/182021>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.