should I run chrome with --no-sandbox in Sandboxie ?

kezz

New member
Chrome has a commandline switch --no-sandbox that from what I understand is supposed to be used in restricted environments where chrome's sandbox causes issues and is better of disabled.

The problem I noticed is if i install chrome into a sandbox and try to run it, I get this message from Sandboxie:

chrome.exe: SBIE2112 Object is not accessible: \device\namedpipe\Sessions\1\AppContainerNamedObjects\S-1-15-2-4262479991-2994206114-3377405323-1270699928-167745150-842232814-7372677425\_Sandbox_me_Chrome_Session_1, call CreateFile (C0000034) access=001F0006 initialized=1 (4)

Using chrome still works fine despite this message, but of course I had to find a fix.

After searching I found the similar issue about Edge:


And the suggested fix by DavidXanatos comment is to add that:

OpenIpcPath=msedge.exe,\Sessions\*\AppContainerNamedObjects\*
OpenFilePath=msedge.exe,\Device\NamedPipe\Sessions\*\AppContainerNamedObjects\*

So I did the same (just changed msedge.exe to chrome.exe) and now I don't get the error message from Sandboxie.

However, I don't know what exactly is this doing? Punching a security hole in Sandboxie? Maybe better to just ignore the message?

After more searching I found the --no-sandbox option of chrome. Using this option also "fixes" the Sandboxie error message.

So there are 3 options to handle this:

  1. Ignore the message and continue
  2. Use DavidXanatos fix with OpenIpcPath/OpenFilePath
  3. Use --no-sandbox commandline switch

I'm just not sure which of these 3 options is truly the best way in terms of security so if anybody has an opinion feel free to share it.
 
I found out about the url chrome://sandbox which shows the difference when using the --no-sandbox switch.

Regular sandbox mode:

sb.png

Using --no-sandbox switch:

nsb.png

And I'm suspecting the msg that I get from Sandboxie ( chrome.exe: SBIE2112 Object is not accessible: \device\namedpipe\Sessions\1\AppContainerNamedObjects\S-1-15-2-4262479991-2994206114-3377405323-1270699928-167745150-842232814-7372677425\_Sandbox_me_Chrome_Session_1, call CreateFile (C0000034) access=001F0006 initialized=1 (4) ) is specifically because of the line I highlighted in yellow, it is the only thing trying to use AppContainer and this is also part of the Sandboxie message AppContainerNamedObjects

So I tried to find out about this Passage Embeddings Service and it seems it is some AI junk that we probably don't even want.

Now I'm thinking more like why even try to workaround this Sandboxie message issue and just let chrome do whatever it wants? Probably better off trying to find a way to disable Passage Embeddings Service and maybe that will stop the message... ?

I don't really know what is the best approach here. OpenIpcPath/OpenFilePath to rid the message could be good as long as it is really necessary and not opening a security hole. I don't know if --no-sandbox is good because it seems to disable all the sandboxing of chrome, and putting all defense up to Sandboxie. So which way really is the best?

edit:
Also, using Process Explorer you can see the AppContainer integrity level:

pe.PNG

This is only when running chrome outside of Sandboxie. Under Sandboxie, every chrome.exe is Untrusted
 
Last edited:
Hello,

I am just going to comment on the following part


There is an issue, reporting to get the same. This had been reported in this forum. Since the issue points to the root cause, as far as I can tell, it should be quicker to fix and Sandboxie's side.
It seems to be a similar issue. But I can say that I use Firefox all the time in my sandboxie and I never had that message from sandoxed Firefox

For me it's only for Chrome. Other chromium based browsers don't have the issue either. It's just specifically Google Chrome for me.

All browsers I install inside the sandbox, never out of the sandbox. From my own experience I can only say that the only issue I saw is with Chrome. No other browsers did I ever see this issue with. And never Firefox either.
 
Back
Top