How to run chrome securely in docker?
Asked Answered
C

1

7

Or, perhaps this boils down to: How do I get or create a working seccomp profile for google-chrome?

I'd like to create a docker image where I launch Google chrome and browse sites I do not trust and do this as safely as possible. There are multiple alternatives. Could you help me choose the safest among them?

If we try to run chrome naively in docker, we'll get this error:

$ google-chrome
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[152:152:0804/063753.226725:FATAL:zygote_host_impl_linux.cc(201)] Check failed: . : Operation not permitted (1)
Trace/breakpoint trap (core dumped)

So we either need to disable the sandbox or allow it to run. The README.md for Zenika/alpine-chrome points out that there are these ways to run chrome under docker:

With --no-sandbox

Run google-chrome --no-sandbox .... I've seen multiple warnings (e.g. 1, 2), that I should trust the visited sites (I don't). Apparently here I'm disabling much of chrome security, so I'm effectively trusting docker 100% for safety. Not great. There is even an entire site dedicated to why --no-sandbox is a bad idea: https://no-sandbox.io/.

When we run chrome with --no-sandbox it also displays this ominous warning upon startup:

You are using an unsupported command-line flag: --no sandbox. Stability and security will suffer.

kasmweb/chrome (and many others) use this approach and even sets up "CommandLineFlagSecurityWarningsEnabled": false in default_managed_policy.json to avoid the resulting warning message.

With SYS_ADMIN capability

Run docker run --cap-add=SYS_ADMIN ... (or worse, using --privileged)

This will give docker the necessary permissions to use the sandbox properly. But I'm worried I'm handing over root to the container, so here I'll trust the browser sandbox 100% with the entire host, which isn't great.

puppeteer/puppeteer suggests using this approach.

"The best": with seccomp

Zenika/alpine-chrome suggests using Jessie Frazelle's chrome.json seccomp profile for Chrome and calls it:

This is The most secure way to run this Headless Chrome docker image.

Launch the container using: docker run --security-opt seccomp=$(pwd)/chrome.json .... However, when I try this, I get the following error, perhaps because I'm not running headless:

$ google-chrome
[90:90:0803/004311.319570:FATAL:spawn_subprocess.cc(221)] posix_spawn: Operation not permitted (1)
Trace/breakpoint trap (core dumped)

I've tried adding spawn and posix_spawn to Jessie Frazelle's chrome.json (following the pattern in the file) but couldn't get rid of this error. Is this seccomp approach really the safest? And if so, how do I modify the chrome.json file to make it work?

Use another browser

Just use firefox and be done with it. But I'd actually like to use chrome.

Chine answered 4/8, 2023 at 5:40 Comment(4)
What did you eventually decide?Housebreak
I am running chromium via playwright. It works in a container as non-root user with the seccomp profile. I am using headless, but there is also a headful option (but one must install the x dependencies). You might want to have a look at how they do that in their official Dockerfile.Housebreak
I previously wrote that I was using --no-sandbox for now, but I eventually decided to run firefox in the container instead since there is no clear safe way to run chrome docker.Indore
I am here with the same question, but usecase is different and based on that my preference is protecting the root access to host machine. I am thinking of going with sandbox and relying on docker for security.Whiles
E
0

I have had a similar issue, for anyone else running into this issue:

The chrome.json file is a list of valid syscalls. posix_spawn is not a syscall, but a library function (which uses syscalls under the hood).

So you can try the following: Set the defaultAction in the chrome.json to SCMP_ACT_LOG and watch your system logs while reproducing the issue. (e.g. journalctl -xef) You should see a reference to the syscall there, which you can use to find out the value you need to put in the seccomp file chrome.json.

Note: If you set the defaultAction to SCMP_ACT_LOG, you will temporarily disable blocking syscalls (allowing them), so it will work while you are logging them.

Empyrean answered 29/8 at 11:50 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.