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

Chrome - Failed to move to new namespace. #65

Closed
xcellardoor opened this issue Sep 23, 2015 · 103 comments
Closed

Chrome - Failed to move to new namespace. #65

xcellardoor opened this issue Sep 23, 2015 · 103 comments

Comments

@xcellardoor
Copy link

@xcellardoor xcellardoor commented Sep 23, 2015

I keep getting this error when trying to run the Chrome image. If I run with the --no-sandbox argument for Chrome, it then complains about running as the root user and dies immediately. What's the solution?

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Sep 23, 2015

The arguments to run in my dotfiles work for me

On Wednesday, September 23, 2015, xcellardoor notifications@github.com
wrote:

I keep getting this error when trying to run the Chrome image. If I run
with the --no-sandbox argument for Chrome, it then complains about running
as the root user and dies immediately. What's the solution?

Failed to move to new namespace: PID namespaces supported, Network
namespace supported, but failed: errno = Operation not permitted


Reply to this email directly or view it on GitHub
#65.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Sep 23, 2015

You should not be using --no-sandbox

On Wednesday, September 23, 2015, xcellardoor notifications@github.com
wrote:

I keep getting this error when trying to run the Chrome image. If I run
with the --no-sandbox argument for Chrome, it then complains about running
as the root user and dies immediately. What's the solution?

Failed to move to new namespace: PID namespaces supported, Network
namespace supported, but failed: errno = Operation not permitted


Reply to this email directly or view it on GitHub
#65.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Sep 23, 2015

Nope sorry still not working. I did a 'make' on your dotfiles and that all seems to have installed okay. Tried re-launching your Chrome and it failed with the same PID issue. Here is the end of installing the dotfiles and then starting the your chrome.

sudo systemctl daemon-reload
╭─cellardoor@glow  ~/github/docker/dotfiles  ‹master› 
╰─$ sudo systemctl daemon-reload 
╭─cellardoor@glow  ~/github/docker/dotfiles  ‹master› 
╰─$ docker run -it --net host --cpuset-cpus 0 --memory 512mb -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY --device /dev/snd jfrazelle/chrome                                                                      1 ↵
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
^C
@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Sep 23, 2015

hmmm gotta be something weird w your setup :/

On Wed, Sep 23, 2015 at 11:15 AM, xcellardoor notifications@github.com
wrote:

Nope sorry still not working. I did a 'make' on your dotfiles and that all
seems to have installed okay. Tried re-launching your Chrome and it failed
with the same PID issue. Here is the end of installing the dotfiles and
then starting the your chrome.

sudo systemctl daemon-reload
╭─cellardoor@glow ~/github/docker/dotfiles ‹master›
╰─$ sudo systemctl daemon-reload
╭─cellardoor@glow ~/github/docker/dotfiles ‹master›
╰─$ docker run -it --net host --cpuset-cpus 0 --memory 512mb -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY --device /dev/snd jfrazelle/chrome 1 ↵
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
^C


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Sep 23, 2015

It's a relatively standard Arch Linux machine, nothing particularly weird about it unfortunately :(

You're not running as a special user are you? Online I've read it's possible to use --no-sandbox to remove the PID error but of course you're forgoing basically everything useful about sandboxing when you do that :| It then says I'm trying to run it as Root too, if using sandboxing. Are you invoking any commands to have it run as a regular user? Is your Docker daemon itself configured differently to stock perhaps?

Thanks.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Sep 23, 2015

i use everything in my dotfiles its a standard docker run

On Wed, Sep 23, 2015 at 11:26 AM, xcellardoor notifications@github.com
wrote:

It's a relatively standard Arch Linux machine, nothing particularly weird
about it unfortunately :(

You're not running as a special user are you? Online I've read it's
possible to use --no-sandbox to remove the PID error but of course you're
forgoing basically everything useful about sandboxing when you do that :|
It then says I'm trying to run it as Root too, if using sandboxing. Are you
invoking any commands to have it run as a regular user? Is your Docker
daemon itself configured differently to stock perhaps?

Thanks.


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Sep 23, 2015

I tried this here for Chrome and it's working (with --no-sandbox, which is evil I know). The extra steps he does is to put a user in the container and then run as that user, it's got to be something to do with that. Just FYI really in case it's ever useful. http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/

@hurricanehrndz
Copy link

@hurricanehrndz hurricanehrndz commented Sep 26, 2015

Can confirm that UID and GID is necessary. Also /dev/dri mapping is also essential otherwise you will have Chrome crashing every couple of tabs.

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Sep 27, 2015

Would you mind sharing how you passed the UID and GID through? What's the exact command you're using to startup this container? Thanks.

@hurricanehrndz
Copy link

@hurricanehrndz hurricanehrndz commented Sep 28, 2015

@xcellardoor

Yeah, I don't mind at all. I actually forked someone's else project and introduce a bunch of fix and features I thought he was missing. You can find the project here:
https://github.com/hurricanehrndz/docker-browser-box

Let me know if you encounter any issues, actually just open one up. Also the readme should be pretty self explanatory. I have not updated the README to point to my docker repo yet, but in case your wondering my username is hurricane on the hub. Feel free to fork though and make pull request.

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Sep 29, 2015

@hurricanehrndz Sorry to abuse Jess' thread, but I can't figure out how to raise an issue with docker-browser-box on your page. Have you turned anything off? Getting some errors now. Could you let me know how to message/raise an issue so I can help resolve the problem. Thanks.

@hurricanehrndz
Copy link

@hurricanehrndz hurricanehrndz commented Sep 29, 2015

@xcellardoor issues are now open. My apologies go @jfrazelle and many thanks because without your hard work none of this would be possible!

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 5, 2015

I'm getting this error on arch linux too. I tried to strace it and here's my understanding of the problem:

It thinks that it's able to create network namespaces and PID namespaces, but it fails when it tries to fork with clone() it fails with the following error:

[pid    20] clone(child_stack=0, flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not permitted)

I'll try to reproduce the error by writing a small C program that does just the clone part.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 5, 2015

its gotta be distro specific, i use this image everyday :/ even right now

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Oct 5, 2015

The question is what does Arch do that Debian (which Jess uses) doesn't. I know Debian tends to value stability and older versions of packages... perhaps there is a complication with a package which cutting-edge Arch uses which Debian etc may soon hit too. I look forward to seeing what @vikstrous finds but if I can test anything for anyone, please ask and I'll be happy to.

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 6, 2015

After reading the man page for clone I found out that chrome needs CAP_SYS_ADMIN to use the CLONE_NEWNET flag. I added --cap-add SYS_ADMIN and I got past the Operation not permitted error. I still get this though:

[1:1:1006/032221:ERROR:nacl_fork_delegate_linux.cc(314)] Bad NaCl helper startup ack (0 bytes)
@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

All of this seems very wrong I do not add that cap what user are you
running as in the container, do you have apparmor or selinux installed?

On Monday, October 5, 2015, Viktor Stanchev notifications@github.com
wrote:

After reading the man page for clone I found out that chrome needs
CAP_SYS_ADMIN to use the CLONE_NEWNET flag. I added --cap-add SYS_ADMIN
and I got past the Operation not permitted error. I still get this though:

[1:1:1006/032221:ERROR:nacl_fork_delegate_linux.cc(314)] Bad NaCl helper startup ack (0 bytes)


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

Mine creates the chrome sandbox just fine I just straced it

On Monday, October 5, 2015, Jessica Frazelle me@jessfraz.com wrote:

All of this seems very wrong I do not add that cap what user are you
running as in the container, do you have apparmor or selinux installed?

On Monday, October 5, 2015, Viktor Stanchev <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

After reading the man page for clone I found out that chrome needs
CAP_SYS_ADMIN to use the CLONE_NEWNET flag. I added --cap-add SYS_ADMIN
and I got past the Operation not permitted error. I still get this
though:

[1:1:1006/032221:ERROR:nacl_fork_delegate_linux.cc(314)] Bad NaCl helper startup ack (0 bytes)


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 6, 2015

I don't have either one. Arch doesn't have them by default.

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 6, 2015

Here's the c file to test with:

https://gist.github.com/vikstrous/151b4c74fc0ab4c10d85

Does this work on your system without --cap-add SYS_ADMIN ?

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Oct 6, 2015

Thank you very much @vikstrous for writing the test. Here are the results:

cellardoor at glow in [~/Temp]
12:01:56 › gcc test.c

cellardoor at glow in [~/Temp]
12:02:02 › ./a.out
Cloning...
Cloning failed with errno 1: Operation not permitted

cellardoor at glow in [~/Temp]
12:02:05 › sudo ./a.out
Cloning...
Parent running.
Child running.
Test successful.

There is a problem with my user being unable to clone the process, but running with sudo as a whim to bypass whatever protection is in place worked.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

Running 'unshare' will also clone just fyi

On Tuesday, October 6, 2015, xcellardoor notifications@github.com wrote:

Thank you very much @vikstrous https://github.com/vikstrous for writing
the test. Here are the results:

cellardoor at glow in [~/Temp]

12:01:56 › gcc test.c

cellardoor at glow in [~/Temp]

12:02:02 › ./a.out
Cloning...
Cloning failed with errno 1: Operation not permitted

cellardoor at glow in [~/Temp]

12:02:05 › sudo ./a.out
Cloning...
Parent running.
Child running.
Test successful.

There is a problem with my user being unable to clone the process, but
running with sudo as a whim to bypass whatever protection is in place
worked.


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

this is the exact command i run, and i am posting this comment from the chrome in a container :p

    docker run -d \
        --memory 3gb \
        --net host \
        -v /etc/localtime:/etc/localtime:ro \
        -v /tmp/.X11-unix:/tmp/.X11-unix \
        -e DISPLAY=unix$DISPLAY \
        -v $HOME/Downloads:/root/Downloads \
        -v $HOME/Pictures:/root/Pictures \
        -v $HOME/Torrents:/root/Torrents \
        -v $HOME/.chrome:/data \
        -v /dev/shm:/dev/shm \
        -v /etc/hosts:/etc/hosts \
        --device /dev/snd \
        --device /dev/dri \
        --device /dev/video0 \
        --group-add audio \
        --group-add video \
        --name chrome \
        jess/chrome --user-data-dir=/data --force-device-scale-factor=1 \
        --proxy-server="$proxy" --host-resolver-rules="$map" "$args"

@vikstrous are u in the office tommorrow we can debug at lunch or something because it seems weird to me

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

also what kernel are you on?

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 6, 2015

and what docker version?

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 6, 2015

Yes, --net host is off. This was on my personal laptop and I don't have it here, but I think the kernel is around 4.2.2 and the docker version is 1.8.2.

On October 6, 2015 10:40:57 AM PDT, Jess Frazelle notifications@github.com wrote:

and what docker version?


Reply to this email directly or view it on GitHub:
#65 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@vikstrous
Copy link

@vikstrous vikstrous commented Oct 7, 2015

I tried Ubuntu in a VM. Here's what I found:

  • I confirmed that Chrome on Ubuntu starts without any special capabilities and without turning off the sandbox.
  • I confirmed that my test binary fails even though Chrome starts with the same config.
  • I don't think --net host changes anything WRT the sandbox
  • I have no idea how X11 does authentication on Ubuntu because clearly it doesn't use .Xauthority
  • I found that I couldn't strace inside the container without --privileged which is kind of weird. This is a bit off topic and it's a kernel issue, but it should be allowed IMO.
  • Arch Linux's kernel is compiled without user namespaces, but Ubuntu has them on. The issue seems to be that CLONE_NEWPID and CLONE_NEWNET are allowed only with CLONE_NEWUSER.

Chrome under ubuntu does a test for them from what I can see:

clone(child_stack=0, flags=CLONE_NEWUSER|SIGCHLD) = 21

On arch this test fails:

clone(child_stack=0, flags=CLONE_NEWUSER|SIGCHLD) = -1 EINVAL (Invalid argument)

Then on Ubuntu chrome does:

clone(child_stack=0x7fff9c88d7c0, flags=CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 22

And on arch it tries:

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9d90f60d10) = 20

Now I know why this behaviour happens. The next question is if there is anything we can do about it.

I see two options that are currently possible for Arch users:

  • Using a custom kernel on Arch
  • Turning off the sandboxing on Arch

I see a few long term options:

  • Figure out how to make Chrome/Chromium fail more elegantly in this scenario and contribute a patch.
  • Get user namespaces enabled in the Arch kernel - https://bugs.archlinux.org/task/36969 - might take a year until things are more settled down and they are comfortable with the security of the feature.
  • I don't know if this is possible, and it's a kernel change, but maybe allow network/pid namespacing without CAP_SYS_ADMIN.
@vikstrous
Copy link

@vikstrous vikstrous commented Oct 7, 2015

Should chrome be allowed to even do clone with CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWUSER? I'm not that familiar with how user namespaces are implemented, so I need to read more before I can figure out if this is normal.

Edit, I think this is indeed normal. This article cleared things up for me: http://lwn.net/Articles/528078/

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Oct 7, 2015

Yeah all that makes sense and you definitely need CLONE_NEWUSER lol I
didn't realize that was missing from the kernel

So mine is using chromiums new namespace sandbox and yours is using the old setuid sandbox which is not as great :p

On Wednesday, October 7, 2015, Viktor Stanchev notifications@github.com
wrote:

Should chrome be allowed to even do clone with CLONE_NEWPID |
CLONE_NEWNET | CLONE_NEWUSER? I'm not that familiar with how user
namespaces are implemented, so I need to read more before I can figure out
if this is normal.


Reply to this email directly or view it on GitHub
#65 (comment)
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@xcellardoor
Copy link
Author

@xcellardoor xcellardoor commented Oct 7, 2015

Guessing you guys are on a roll in pinpointing the problem :)

@jfrazelle Tested your command this morning, turned off the -d flag so I could see what is put out on the CLI. Same problem as before so it definitely looks to be a sandboxing/namespaces issue on Arch. I could take a look into popping a custom kernel on here, it takes a few minutes so I don't mind.

Can either of you recommend any community built kernels that you know wouldn't implement these protections? I'm taking a look at Zen Kernel at the moment, for which Arch has a repo package. So far my Google-fu hasn't got a definitive answer. To make sure I understand, I'm after user-namespaces ON, but a greater priority is sandboxing OFF?

If it helps, my versions are:
Kernel - 4.2.2-1-ARCH
Docker - 1.8.2

cellardoor at glow in [~]   
10:05:08 ›     docker run \   
        --memory 3gb \
        --net host \
        -v /etc/localtime:/etc/localtime:ro \
        -v /tmp/.X11-unix:/tmp/.X11-unix \
        -e DISPLAY=unix$DISPLAY \
        -v $HOME/Downloads:/root/Downloads \
        -v $HOME/Pictures:/root/Pictures \
        -v $HOME/Torrents:/root/Torrents \
        -v $HOME/.chrome:/data \
        -v /dev/shm:/dev/shm \
        -v /etc/hosts:/etc/hosts \
        --device /dev/snd \
        --device /dev/dri \
        --device /dev/video0 \
        --group-add audio \
        --group-add video \
        --name chrome \
        jess/chrome --user-data-dir=/data --force-device-scale-factor=1 \
        --proxy-server="$proxy" --host-resolver-rules="$map" "$args"
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
@nickabbey
Copy link

@nickabbey nickabbey commented May 27, 2017

fixed with xhost +
I'll circle back to make that more secure later, but for now, it's working beautifully.

Thanks for all your container work, and for the fast reply.

@akostadinov
Copy link

@akostadinov akostadinov commented Nov 16, 2017

It is better to disable sandboxing than disable selinux and running as root. It doesn't make sense to remove security of your entire host, just to run chrome with sandboxing. If your container is running as non-root and with selinux isolating it from the rest of the system, you don't have to worry about chrome IMO. Especially if sole purpose of container is testing.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Nov 16, 2017

@akostadinov
Copy link

@akostadinov akostadinov commented Nov 16, 2017

@jessfraz , fixed where? If you mean fixed in chrome (to not use forbidden features) I would agree. But the other fixes I read over the internet all involve reducing container security to unknown state.

If container runtime has put restrictions over what you can do from inside the container, chances are the big and experienced security team of said container runtime knew why these restrictions are set better than you. By randomly removing restrictions, this is asking for trouble. Containers provide a false sense of security, but without the proper restrictions, you can easily break out of them.

I would say that removing container restrictions and compiling custom kernels is 99% more likely to be a bad idea than running chrome without sandboxing. Would make sense only in certain use cases. Especially for the average no-clue-about-security developer.

Additional evidence is OpenSSH and privilege separation. It is mandatory in latest version but they patched it such that it skips protections that are not possible in a restricted container environment.

Too bad Chrome is not at that yet. Somebody should file a bug I guess.

Or if you know how to make Chrome run with sandboxing and without compromising security of my OpenShift cluster, let me know.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Nov 16, 2017

If container runtime has put restrictions over what you can do from inside the container, chances are the big and experienced security team of said container runtime knew why these restrictions are set better than you.

You know I literally wrote a lot of those "container runtime" defaults you speak of.

@akostadinov
Copy link

@akostadinov akostadinov commented Nov 16, 2017

I didn't want to question your competency to decide what level of protection is ok for your own use cases. I'm just saying that the advice I see above is wrong for the average (and even above average) users without clear explanation of the pros and cons in different use cases.

Or maybe I'm thinking about production use cases where security is more important, e.g. compared to just run some test stuff without messing up my machine with experimental libs and software.

I'm leaving it here though. I can't argue against no arguments. Everybody should check what guarantees the underlying container runtime is providing and make sure breaking those is acceptable for him/her.

@jessfraz
Copy link
Owner

@jessfraz jessfraz commented Nov 16, 2017

@yngwietiger
Copy link

@yngwietiger yngwietiger commented Feb 3, 2018

Nice thread!

FWIW, I was able to get Chrome running on a CentOS image with a couple of minor changes to the default.json file (adding "clone" and "unshare").

#341

@ebr
Copy link

@ebr ebr commented Jul 1, 2018

@vikstrous Apologies for resurrecting an old thread, but I'm wondering about your comment re: --no-sandbox option:

With the sandbox disabled it's easier to compromise the Chrome within the container and if that happens it can use the x11 access to do keylogging, screenshots, keyboard emulation and other bad things.

This is understood. However, my use-case is very narrow (headless SVG to PNG conversion), and I can't use @jessfraz's seccomp profile in my environment. My only other option is adding CAP_SYS_ADMIN which is clearly worse than --no-sandbox. Given all of the above, I fail to see any practical security concerns with using --no-sandbox, but feel like I'm missing something, so would really appreciate any comment and/or advice. Thanks!

@vikstrous
Copy link

@vikstrous vikstrous commented Jul 4, 2018

Headless usage and disabling chrome sandboxing

@ebr if the x11 server that chrome is connecting to is containerized along with chrome, I can see how --no-sandbox might be a good solution. (If chrome doesn't need x11 in that mode, even better.) When I said it's a bad idea to run it with --no-sandbox I was specifically referring to the case where you are using it as a browser to handle untrusted input and giving it access to your x11 user session. In your case the input is probably untrusted, but you don't have the same level of exposure because there's no x11 user session. If you can keep the x11 server chrome is using containerized in the same container or a sidecar container, you can isolate the potential damage. You would be relying on docker's containerization instead of chrome's in this case and all the usual docker hardening approaches can be used.

TLDR: IMO it's not an issue because you'd still have docker's sandboxing. Just don't give it access to your user's x11 session.

@lukasholzer
Copy link

@lukasholzer lukasholzer commented Sep 20, 2018

@vik-y have you tried --cap-add=SYS_ADMIN when starting container?

Thanks so much I tried a lot of things but this was the only thing that worked!

@cnicodeme
Copy link

@cnicodeme cnicodeme commented Nov 6, 2018

@vikstrous I'm trying to wrap my ahead around if I should set the "--no-sandbox" mode or not in my Google Chrome instance. Your comment is helping me about this.

If Google Chrome is run with that --no-sandbox parameter in a docker, at AWS Fargate, does that still makes a security issue or since you have the sandboxing from Docker, in an AWS Fargate farm, without X11 (--headless) mode, it's secure?

I'm missing a few bits to answer this question. I'm hoping you'll have them.
Thanks!

@ddj116
Copy link

@ddj116 ddj116 commented Jan 7, 2019

Great thread, thanks to everyone that has contributed here! I've now got chrome running in a container, using Jess's Dockerfile and the last couple issues were:

  • Errors cannot open display: unix:0.0 -- fixed by running xhost +"local:docker@" on the host
  • Sound wasn't working -- fixed with the solution suggested here, adding --group-add $(getent group audio | cut -d: -f3) to the docker run line
@rayvtoll
Copy link

@rayvtoll rayvtoll commented Jun 21, 2019

seccomp=$HOME/chrome.json made it all work when creating chrome application for my container desktop environment https://github.com/rayvtoll/vcde

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet