Some of the mitigations described in sandbox_policy.h and security_level.h have extra constraints that aren't listed there, so if they're applied blindly then sandbox setup may fail. The extra steps needed should be documented:

(1)

MITIGATION_RELOCATE_IMAGE and MITIGATION_RELOCATE_IMAGE_REQUIRED don't work in debug builds. (If they are both set, SpawnTarget returns SBOX_ERROR_GENERIC. I haven't tried setting just one of the two.)

process_mitigations_test.cc contains comments implying they shouldn't work in debug builds at all:

#if defined(NDEBUG)  // ASLR cannot be forced in debug builds.
  mitigations |= MITIGATION_RELOCATE_IMAGE | MITIGATION_RELOCATE_IMAGE_REQUIRED;
#endif

But in my testing, there are no errors setting them with SetDelayedProcessMitigations in a debug build. To summarize:

Release build:
SetProcessMitigations: SpawnTarget succeeds
SetProcessDelayedMitigations: SpawnTarget succeeds

Debug build:
SetProcessMitigations: SpawnTarget returns SBOX_ERROR_GENERIC
SetProcessDelayedMitigations: SpawnTarget succeeds

CanSetProcessMitigationsPostStartup lists RELOCATE_IMAGE and RELOCATE_IMAGE_REQUIRED as mitigations that can be applied post-startup, so it seems like adding it with SetDelayedProcessMitigations should work. But the comment in the test implies that in a debug build it shouldn't work at all, so I'm not sure if it's actually doing anything in this case.

Also, wfh notes:

"FWIW we don't seem to use either MITIGATION_RELOCATE_IMAGE  or MITIGATION_RELOCATE_IMAGE_REQUIRED in the content sandbox right now. I'd have to dig in the history to work out why but my guess would be that they have been superceded by other mitigations we use instead, for example high entropy ASLR."

So, we should do one or both of: (a) find out whether these two mitigations will actually work in a debug build if applied with SetProcessDelayedMitigations, and if so, add test this in the ProcessMitigationsTest.CheckWin8 unit test; or (b) decide that these two mitigations are deprecated and what should be used instead. And whatever is decided, document it in the header.

(2)

IF MITIGATION_WIN32K_DISABLE is used on a target process linked to user32.dll or gdi32.dll, ResumeThread will fail with an error message: "The application was unable to start correctly (0xc0000142)." The root cause and workaround are described in http://docs/document/u/1/d/1gJDlk-9xkh6_8M_awrczWCaUuyr0Zd2TKjNBCiPO_G4/mobilebasic#h.ac29fdlvzgvf: 

  policy->AddRule(sandbox::SUBSYS_WIN32K_LOCKDOWN, sandbox::FAKE_USER_GDI_INIT, nullptr);

This should be documented in the header.