How does a hacker get access to the root user when disabling the sandbox in puppeteer, and what does it look like?
You'll see stuff like the first comment here that adding the --no-sandbox flag when launching puppeteer "is a giant security hole" (upvoted many times). Puppeteer troubleshooting docs say "running without a sandbox is strongly discouraged". Yet, it appears that you must run with this flag on Google Cloud Run and AWS Lambda for some reason. So what is the problem again? And many examples on the web use this flag.
Those troubleshooting docs explain the alternatives to that flag, which don't work on the serverless cloud tools, but it might help in answering this question.
- Enable user namespace cloning (recommended, even though it also seems to introduce a lesser security hole).
- Setup setuid sandbox.
Can you explain in a little detail an example scenario of what a hacker can do if that flag is enabled (or if you don't know puppeteer, what it means to not have the sandbox)? I think it will help me as well as be a general source of truth for people looking to run a tool like puppeteer in production, what kinds of security holes it might introduce into your infrastructure.
A helpful scenario illustration would include how the hacker gains access to the root user on the operating system (at a high level), and what they can do with that access in practice? (Does it mean they can then steal your ENV variables set through Google Cloud Run, and gain access to all your credentials, and take down your app or run amok in running up your bill because they have all your private keys? Does it mean they can get access to your social security number or something? Or is it less than that, they can't get access to your keys, but they can get access to logs or something. I just don't know what the scope is of it....).
