What's the actual danger with --no-sandbox and --disable-setuid-sandbox

[kalepail]

I'm running playwright in a Glitch app but it won't work unless I run under --no-sandbox and --disable-setuid-sandbox flags. Everywhere says this is insecure but I can't find any documentation or examples on why or how running under these flags is dangerous. Could someone provide some example code showing how these flags enable exploitation?

What specifically are the dangers? Memory and CPU consumption? Can secret server files somehow be accessed? Security issuers are different than performance issues so I'd like to know what some tests are I could run to see if there are other ways to mitigate the actual issues everyone seems to think are there but never show what.

Thanks!

[nrayburn-tech]

Here is a link from google that explains it quite a bit, somebody else may be able to give you a good summary though.
https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox_faq.md

And if you are really interested, here is another link for it.
https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md

[kalepail]

This is really interesting and helpful though I would still love to see a specific example or scenario where not using a sandbox opens up X vulnerability through Y code while using a sandbox mitigates that risk.

[pavelfeldman]

@tyvdh : tl/dr is quite straightforward. With no sandbox, if you open a malicious site that you do not control that actively tries to exploit some of the chromium vulnerabilities, it can gain full access to your user session. It will be able to do things that the logged in user can do.

So disabling the sandbox is only Ok when you either

• trust the web content you open. I.e. that's your own site that does not load random untrusted iframes.
• you open untrusted content, but your browser is running in a restricted environment such as a virtual machine and there is no secret data siting next to it.