Hi Ludo,

I ran into this bug today, so I took a look through this...

Ludovic Courtès <ludo@gnu.org> writes:

> Julien Lepiller <julien@lepiller.eu> skribis:
>
>> Le 21 janvier 2019 09:24:53 GMT+01:00, Ricardo Wurmus <rekado@elephly.net> a écrit :
>>>
>>>Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hi Julien,
>>>>
>>>> Julien Lepiller <julien@lepiller.eu> skribis:
>>>>
>>>>> Try setting security.sandbox.content.read_path_whitelist to
>>>/gnu/store/
>>>>> (with a leading /) in about:config.
>>>>
>>>> Setting it to “/gnu/store/” (with a trailing slash) works, thank you!
>>>>
>>>> It turns out that setting LIBGL_DRIVERS_PATH is even unnecessary.
>>>>
>>>> I suppose we should patch the default value of
>>>> ‘security.sandbox.content.read_path_whitelist’ in our package.  What
>>>do
>>>> people think?
>>>
>>>It isn’t much of a sandbox if all of /gnu/store would be permitted. 
>>>Can
>>>this be reduced to the paths of store items that are known at build
>>>time?
>>
>> You'll have to list every library and there dependencies. Is that
>> possible?
>
> That would be possible, yes, though we’d have the build-time
> dependencies rather than the run-time dependencies (since we cannot know
> the run-time dependencies until IceCat is built.)
>
> That said putting all of /gnu/store wouldn’t be that bad I think—at
> least user data remains inaccessible, which is much better than exposing
> /usr on FHS distros.
>
> Thoughts?
>
> Ludo’.

While it looks like preliminary precise whitelisting was done for
ffmpeg, it seems that this approach may require excessive effort for
WebGL.  I've attached a security sandbox log generated with

  MOZ_SANDBOX_LOGGING=1 icecat https://get.webgl.org

using Guix's default value of security.sandbox.content.read_path_whitelist.

You see that it does whitelist paths from ld.so.conf, but that isn't
enough.  It seems some of the paths it tries to read (notably, the last)
aren't even in icecat's inputs.  For example, after whitelisting libxcb,
it needs

  /gnu/store/w68jrgqqbfcakm27wm4zf7hmpgw294my-libxxf86vm-1.1.4/lib/libXxf86vm.so.1

and after whitelisting that one,

  /gnu/store/jwga98k68l0h5c45jx7z4jdjzhfc34vm-libxshmfence-1.3/lib/libxshmfence.so.1

and so on.  Both the above are propagated-inputs in mesa.  So, it seems
to "properly" fix this, we would need to read *all* input libraries
recursively.  I've also attached a successful log (with
read_path_whitelist set to "/gnu/store/").

Until someone devises a method to do that, whitelisting "/gnu/store/"
seems like the best option.  I've attached a patch for that.

--
Sarah