Eliminate --no-sandbox option #8
Comments
johnboyes
added a commit
to agilepathway/gauge-taiko-template
that referenced
this issue
Nov 29, 2020
The Chromium browser has to run in headless mode when we are running in a devcontainer (e.g. GitHub Codespaces). Also, we need to run the container without [seccomp][1] restrictions, otherwise we receive an error when running the specifications, saying that there is no usable sandbox for Chromium to run in. It would be nice if we could use a [custom seccomp profile][2], rather than removing all seccomp restrictions entirely, but it appears that Codespaces doesn't currently allow custom seccomp profiles. Certainly the [docs for the (now-obsolete) Visual Studio Codespaces say that][3]. [1] https://docs.docker.com/engine/security/seccomp/ [2] jlund/docker-chrome-pulseaudio#8 (comment) [3] https://docs.microsoft.com/en-us/visualstudio/codespaces/reference/configuring#docker-properties
johnboyes
added a commit
to agilepathway/gauge-taiko-template
that referenced
this issue
Nov 29, 2020
The Chromium browser has to run in headless mode when we are running in a devcontainer (e.g. GitHub Codespaces). Also, we need to run the container without [seccomp][1] restrictions, otherwise we receive an error when running the specifications, saying that there is no usable sandbox for Chromium to run in. It would be nice if we could use a [custom seccomp profile][2], rather than removing all seccomp restrictions entirely, but it appears that Codespaces doesn't currently allow custom seccomp profiles. Certainly the [docs for the (now-obsolete) Visual Studio Codespaces say that][3]. [1]: https://docs.docker.com/engine/security/seccomp/ [2]: jlund/docker-chrome-pulseaudio#8 (comment) [3]: https://docs.microsoft.com/en-us/visualstudio/codespaces/reference/configuring#docker-properties
johnboyes
added a commit
to agilepathway/gauge-taiko-template
that referenced
this issue
Nov 29, 2020
The Gauge specifications pass successfully on the GitHub Codespaces environment. * Add default Gauge and Taiko project files These files were all generated by running: `gauge init js` * Fix typo in comment * Ignore generated Taiko Dockerfile linting issues We are not currently using this Dockerfile, so we don't need to fix the issues reported in the linting at this point of time. If we do ever use this Dockerfile we should then unignore the issues and address the issues reported. * Enable Chromium to run on devcontainer The Chromium browser has to run in headless mode when we are running in a devcontainer (e.g. GitHub Codespaces). Also, we need to run the container without [seccomp][1] restrictions, otherwise we receive an error when running the specifications, saying that there is no usable sandbox for Chromium to run in. It would be nice if we could use a [custom seccomp profile][2], rather than removing all seccomp restrictions entirely, but it appears that Codespaces doesn't currently allow custom seccomp profiles. Certainly the [docs for the (now-obsolete) Visual Studio Codespaces say that][3]. [1]: https://docs.docker.com/engine/security/seccomp/ [2]: jlund/docker-chrome-pulseaudio#8 (comment) [3]: https://docs.microsoft.com/en-us/visualstudio/codespaces/reference/configuring#docker-properties * Add Gauge file associations to VSCode * Install Gauge VSCode extension on devcontainer * Install npm packages on devcontainer
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
--security-opt=seccomp:unconfined.docker run -d --security-opt=seccomp:unconfined -p 127.0.0.1:2222:22 chromeSince 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.
Update: 8/2/2016:
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:
/etc/seccomp/chrome.json, the docker run command would be encoded as:docker run -d --security-opt 'seccomp=/etc/seccomp/chrome.json' -p 127.0.0.1:2222:22 chromePlease 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.
The text was updated successfully, but these errors were encountered: