Hey Kip,
We should probably move this to a different thread....
The parent process has full privileges, so it can read whatever it wants.
As long as we express the IPC in a way that the parent can enforce rules
about filesystem access, basically so the child process doesn't use the IPC
as a generic "I can access _all_ the files now", I don't see a problem with
remoting these access. This lets us avoid needing to maintain more
variations in sandbox rules.
Alex
On Tue, May 9, 2017 at 7:08 PM, Kearwood Kip Gilbert <kgilb...@mozilla.com>
wrote:
> +cc Diego, who has experimented with packaging Firefox on Steam...
>
>
>
> Thanks Alex,
>
>
>
> It sounds as though we can work around all of these issues, based on your
> feedback. I believe that we could proxy any file access needed by the
> content process. The main process will need to access some resources in
> these builds that are not normally accessed by the normal Firefox builds
> for the Steam integration. Perhaps opening these resources isn’t too much
> concern for the regular Firefox builds. If not, we could perhaps select
> these alternate sandboxing rules with a command-line parameter?
>
>
>
> We have also explored treating this “Steam VR Browser” as a separate
> product, and using compile-time flags to select the desired code to build
> and assets. We could still hard-code the rules, but skip them at build
> time for regular Firefox builds. In this case, we are effectively forking
> the “browser” directory into a “vrbrowser” and stripping it down to just
> what we need.
>
>
>
> We liked the re-pack option (ie. Similar to QBRT), as we don’t have to put
> as much load on our test infrastructure; however, this is still an option
> on the table if a dedicated build and the associated costs is justified.
>
>
>
> Cheers,
>
> - Kearwood “Kip” Gilbert
>
>
>
> *From: *Alex Gaynor <agay...@mozilla.com>
> *Sent: *May 9, 2017 7:58 AM
> *To: *Kearwood Kip Gilbert <kgilb...@mozilla.com>
> *Cc: *dev-platform@lists.mozilla.org
> *Subject: *Re: Running mochitest on packaged builds with the sandbox
>
>
>
> Hi,
>
> Hmm, VR appears to be an interesting challenge.
>
> To expand a bit more on why mochitest+sandboxing is a challenge for
> packaged builds: The way mochitest is set up is that there's a
> configuration file which points to JS files to be loaded for tests. These
> are loaded by the content process. This works ok in non-packaged builds,
> because in those builds we allow read access to the entire source directory
> ("topsrcdir"); in packaged builds, we don't have this whitelist -- we only
> allow read access inside of the .app (to use the macOS lingo), so
> essentially content is trying to open a random JS file, and is blocked.
>
> With that context, disabling sandboxing might be one option, another is
> for your repack to include the mochitest JS files inside the packaged
> build, then everything can work ok. We don't want to do this for general
> packaged builds because there's no reason for SuperPowers.js (for example)
> to be in a shipped FF, but if you're doing a special pack for testing it
> might make sense.
>
> Does that make sense?
>
> For your other question, about configuration of sandboxing rules. Right
> now we have the ability to have multiple different sets of sandbox rules,
> for example plugin processes and content processes have different sandbox
> rules, and so will GPU processes soon. With that said, it sounds like what
> you're talking about is really in the content process -- for that case,
> you're really better off remoting access to these resources through the
> parent process. This keeps us from expanding the attack surface in content
> (which is most exposed to the dangerous web), right now we're doing all we
> can to restrict this, so I wouldn't be excited about opening it back up :-)
>
> Cheers,
>
> Alex
>
>
>
> On Mon, May 8, 2017 at 2:14 PM, Kearwood Kip Gilbert <kgilb...@mozilla.com>
> wrote:
>
> Hi all,
>
>
>
> The VR team is working on a Steam packaged browser with a VR specific UI
> and richer VR experience. In order to prevent the overhead of having the
> VR specific assets included in every Firefox build while still running on
> tested executables, we will be doing a repack build.
>
>
>
> WebVR will still continue to be supported in the regular Firefox builds;
> API surface area is the same in normal desktop builds. Mochitests
> validating these API calls should be unaffected.
>
>
>
> We will need a means for testing the VR frontend and assets that are added
> with the re-pack. Ideally, we could use the existing test mechanisms,
> including mochitests.
>
>
>
> Perhaps we could disable the sandbox for these front-end tests?
>
>
>
> The Steam packaged builds will also need slightly expanded access to
> resources such as files, registry, and pipes required for communication
> with Steam.
>
>
>
> Are there any plans to make the sandboxing rules configurable at runtime?
>
>
>
> Cheers,
>
> - Kearwood “Kip” Gilbert
>
>
>
>
>
> *From: *Alex Gaynor <agay...@mozilla.com>
> *Sent: *May 8, 2017 10:26 AM
> *To: *dev-platform@lists.mozilla.org
> *Subject: *Running mochitest on packaged builds with the sandbox
>
>
>
> Hi dev-platform,
>
>
>
> Top-line question: Do you rely on being able to run mochitests from a
>
> packaged build (`--appname`)?
>
>
>
> Context:
>
>
>
> The sandboxing team has been hard at work making the content process
>
> sandbox as restrictive as possible. Our latest focus is removing file read
>
> permissions from content processes -- the sandbox's value is pretty limited
>
> if a compromised content process can ship all your files off by itself!
>
>
>
> One of the things we've discovered in the process of developing these
>
> patches is that they break running mochitest on packaged firefox builds
>
> (this is the `--appname` flag to mochitest)! `try` doesn't appear to use
>
> this, and none of us use it in our development workflows, but we wanted to
>
> check in with dev-platform and see if we were going to be breaking people's
>
> development flows! While these restrictions are not on by default yet, once
>
> they are you'd only be able to run tests on packaged builds by disabling
>
> the sandbox. If this is a fundamental part of lots of folks' workflows
>
> we'll dig into whether there's a way to keep this working.
>
>
>
> Happy Monday!
>
> Alex
>
> _______________________________________________
>
> dev-platform mailing list
>
> dev-platform@lists.mozilla.org
>
> https://lists.mozilla.org/listinfo/dev-platform
>
>
>
>
>
>
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
