CEF3: Enable sandbox support

[GoogleCodeExporter]

Enable sandbox support. See http://magpcss.org/ceforum/viewtopic.php?f=10&t=645 
for CEF3 information.

Original issue reported on code.google.com by magreenb...@gmail.com on 13 Feb 2012 at 7:18

[GoogleCodeExporter]

What exactly is stopping us from just adding a setting in CefSettings that 
allows sandbox. and Just not use the --no-sandbox argument if the setting is 
set?

In a forum thread you have said that there are some assumptions made about the 
executable, what did you mean by that?

Are those just the obvious sandbox assumptions (no file access, no network 
access, restricted win32 calls, etc..) Or is it something beyond that?

Is CEF breaking those assumptions by itself, or are we using --no-sandbox in 
case the CEF clients break those assumptions?

Original comment by Daniel.S...@gmail.com on 17 Sep 2013 at 5:20

[GoogleCodeExporter]

The executable needs to be structured in a specific way in order to support the 
sandbox hooks. That likely means creating a new target that includes the 
necessary Chromium libraries (at a minimum sandbox/sandbox.gyp:sandbox on 
Windows and Linux) and that links statically with the client application. It 
may also require that the non-browser processes use a separate executable.

See http://magpcss.org/ceforum/viewtopic.php?f=10&t=11126 for a description of 
the sandbox-related errors generated on Windows.

See http://dev.chromium.org/developers/design-documents/sandbox for more 
information on Chromium's sandbox implementation. The standalone sandbox 
project can be used to explore and better understand the implementation. See 
http://stackoverflow.com/questions/1590337/using-the-google-chrome-sandbox for 
related (but possibly outdated) discussion.

Original comment by magreenb...@gmail.com on 8 Nov 2013 at 6:33

[GoogleCodeExporter]

On Windows and Linux the sandbox target needs to be compiled into both the 
browser and sub-process executables (not a separate DLL). SANDBOX_EXPORTS needs 
to be defined when building if a separate executable will be used for 
sub-processes -- this code path is untested in Chromium and may be buggy. 
Related discussion:

https://groups.google.com/forum/#!topic/chromium-dev/9u4whVcknoE
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/DPzZ3S3Yhsk/UD
ow64EFSuoJ

Original comment by magreenb...@gmail.com on 14 Nov 2013 at 6:18

[GoogleCodeExporter]

@comment#3: The sandbox linking requirement is only on Windows, not Linux.

Trunk revision 1518 adds sandbox support.
- The sandbox is now enabled by default on all platforms. Use the 
CefSettings.no_sandbox option or the "no-sandbox" command-line flag to disable 
sandbox support.
- Windows: See cef_sandbox_win.h for requirements to enable sandbox support.
- Windows: If Visual Studio isn't installed in the standard location set the 
CEF_VCVARS environment variable before running make_distrib.py or automate.py 
(see msvs_env.bat).
- Linux: For binary distributions a new chrome-sandbox executable with SUID 
permissions must be placed next to the CEF executable. See 
https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for details 
on setting up the development environment when building CEF from source code.

Original comment by magreenb...@gmail.com on 15 Nov 2013 at 6:48

• Changed state: Fixed

[GoogleCodeExporter]

Trunk revision 1546 adds a CEF_ENABLE_SANDBOX define in cefclient and cefsimple 
to make disabling the sandbox easier for non-VS2010 builds of the binary 
distribution.

Original comment by magreenb...@gmail.com on 9 Dec 2013 at 4:39

[GoogleCodeExporter]

The sandbox library can be built fine with VS versions other than 2010? The CEF 
Python project must use VS2008.

Original comment by czarek.t...@gmail.com on 8 Jan 2014 at 3:41

[GoogleCodeExporter]

@comment#6: I haven't tested it with VS2008, but it probably won't work (static 
libraries that include std types generally don't link across VS versions). You 
will need to build CEF/Chromium with VS2008 to get a sandbox library that will 
work with VS2008.

Original comment by magreenb...@gmail.com on 8 Jan 2014 at 3:46

[GoogleCodeExporter]

This document describes the current Chromium sandbox implementation on various 
platforms and plans for refactoring it: 
https://docs.google.com/document/d/1H-hCsIcMsAEP0fWHimbuiNA-Hc9eXEmR94eb-2RQAhA/
edit

Original comment by magreenb...@gmail.com on 20 Feb 2014 at 7:50

[GoogleCodeExporter]

I find this topic from magpcss.org - 
http://www.magpcss.org/ceforum/viewtopic.php?f=10&t=12073

I have this message in dbgview - [9524] 
[1023/012219:ERROR:renderer_main.cc(207)] Running without renderer sandbox
And I suppose this happens because sandbox was not activated. According with 
sandbox requirements - it is not possible to use sandbox with our architecture. 
I just want to mention this so maybe it is possible to make some adjustments so 
it will fit architecture of most apps.

cef_sandbox_win.h file says:
// To enable the sandbox on Windows the following requirements must be met:
// 1. Use the same executable for the browser process and all sub-processes.
// 2. Link the executable with the cef_sandbox static library.
// 3. Call the cef_sandbox_info_create() function from within the executable
//    (not from a separate DLL) and pass the resulting pointer into both the
//    CefExecutProcess() and CefInitialize() functions via the
//    |windows_sandbox_info| parameter.

But we have following troubles with these requirements:
1. Our application is heavy with dependencies - so it is not optimal to use 
same executable (app. may have 10, may have even 20 browser instances), so we 
have separate light-weight executable that loads CEF binaries.
2. Our main application exe compiled in C# - so it is not possible to link with 
C++ lib.
3. Our main application, and components used by application, and some other 
applications uses CEF. So we created special CEF wrapper with some common 
interfaces that deal with CEF API inside. So when CEF API changed - we can fix 
our wrapper and all applications will still work without too much integration 
work. We can easily upgrade or downgrade (if we see issues), use CEF3 or CEF1 
by changing wrapper. So application don't care about CEF sandboxes, etc. This 
special wrapper DLL should handle everything inside. Browser process loads this 
wrapper and calls special wrapper function that calls CefExecuteProcess 
function.
4. Build executable directly with CEF requires application to be compiled in VC 
2013 (I can not compile CEF projects in VS2010, seems because of incompatible 
libs).

Original comment by v...@splitmedialabs.com on 22 Oct 2014 at 9:59

[GoogleCodeExporter]

@#9: Using the same executable for the main process and sub-processes is 
unfortunately a hard requirement to enable the sandbox on Windows. The sandbox 
implementation uses attributes of the currently loaded main process to identify 
the correct locations to hook in the sub-process. This identification process 
fails if the executables are different. See the links in comment #3 for related 
discussion.

Original comment by magreenb...@gmail.com on 23 Oct 2014 at 6:12