Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate --no-sandbox option #8

Open
WhisperingChaos opened this issue Jul 19, 2016 · 0 comments

Comments

@WhisperingChaos
Copy link

commented Jul 19, 2016

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 chrome

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.

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 chrome

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.