Open Bug 983415 Opened 10 years ago Updated 2 years ago

Use procmon to see if we need to allow any filesystem or registry access

Categories

(Core :: Security, defect)

x86
Windows 8.1
defect

Tracking

()

People

(Reporter: bbondy, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

I don't think we have tests on e10s in a good enough state to tell us what's broken when enabling the Windows sandbox. But we should use process monitor to detect the filesystem and registry accesses for the PID matching the content process.

From there we can detect filesystem access that should work but doesn't under the sandbox.  Then we can either allow it via a simple Chromium allow fS path API or change how the filesystem access works.
Attached patch Part 1: add Sysinternals Process Monitor files (obsolete) (deleted) — Splinter Review
These are just the files that come in the procmon zip.
It includes licence and help file.

I'm keeping these separate, partly because of the large binary files, but also because we might use a different method to get these onto machines.
This patch adds a --procmon option so that you can run:

mach mochitest-plain --e10s --procmon path-to-test

You don't have to run it with --e10s or with the sandbox compile option.

Either way it:
* Before tests - starts procmon in a separate process loading configuration file testing/mochitest/procmon/sandboxLogging.pmc.
  The log file for events is testing/mochitest/procmon/sandboxLogging.pml.
  The filter is set up to only include events for plugin-container and FlashPlayerPlugin* on top of some of the standard exclusions.
  It also excludes a whole host of result codes in which I don't think we're interested.
  Unfortunately, exclusions still get written to the log file. You can't just include just the result codes you want as they get updated asynchronously after the include filters are applied ... so you end up with nothing.
* After tests - stops procmon.
* Runs another procmon process to reset it to use the Paging File.
* Stops this process.
* Then exports the log file, this time with the full filter applied.
  Exports this filtered file to XML, this includes stack traces with resolved symbols where possible.
  Deletes the unfiltered log file.


If you get annoyed by the UAC elevation prompt, you can set it to allow auto-elevation for local admins in Group Policy.

* Run mmc and add Group Policy Object Editor snap-in (for Windows 8, if this doesn't work, I think you can search for policy in Settings).
* Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options->User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode ... set this to "Elevate without prompting" ... (nice and easy to find!)

This does reduce security, because if a local admin account was compromised it could run anything without ever getting the UAC elevation prompt, but it's probably a small risk.
Attachment #8419389 - Attachment description: Part 2: script changes to add a --procmon option when runningtests with machmochitestProcmonOption.patch → Part 2: script changes to add a --procmon option when running tests with mach
Attachment #8419369 - Attachment is obsolete: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: