Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Eliminate --no-sandbox option #8
Starting with v1.10, Docker implements a global default seccomp profile that's inherited by every started container. This profile disables one or more kernel calls needed by the initial container process, sshd in this instance, to start chrome's controlling browser process with the ability to issue the system calls essential to construct the chrome sandbox. At this time, I don't precisely know the kernel calls issued by chrome's browser process that are prohibited by Docker, however, the docker run command implements an option permitting root container processes (process having no container process as an ancestor), like sshd, to issue any kernel command. Simply specify the option
Since enabling all kernel calls probably results in a more constrained chrome sandbox, as compared to the sandboxing offered by Docker's default container security when running chrome with the --no-sandbox option, starting the container with the unconfined seccomp value likely offers more security until a minimum seccomp profile can be discerned for the root container process that will allow the browser process to successfully construct chrome's sandbox.
Jess Frazelle provides a similar Docker Chrome solution which has been recently transitioned to runc. It seems both her solutions required tweaking to accommodate seccomp enforcement. She created a custom seccomp profile for Chrome which also passes the smoke test when used to run your (jlund's) docker-chrome-pulseaudio image. Assuming the custom seccomp profile was copied to:
Please note the link to the custom seccomp profile refers to a repository's master branch, therefore, its contents can change potentially rendering it inapplicable for arbitrary configurations/versions of Docker, kernel, and host distributions.