[dimiprasakis]

Neat project, I like the idea. One thing from a quick read: you launch Chrome with --no-sandbox. Is there a good reason for that? Security wise it's probably not a good idea. If there is no reason, I'd suggest leaving the sandbox on!

In any case, cool stuff :)

[nikisweeting]

--no-sandbox is needed in docker, maybe they assume it will mostly run in docker?

[tamnd]

Exactly. For downloading, Kage requires Chrome or Chromium. Running it inside Docker makes setup easier and keeps cleanup simple:

https://github.com/tamnd/kage/blob/main/Dockerfile

Btw, let me think the way to only enable this when running inside Docker.

[nikisweeting]

Docker is designed to be undetectable by default, the best way I have found is to set env IN_DOCKER=True manually in your Dockerfile + check that there is no $DISPLAY configured + that you're on linux. Usually if all/most of those are true you can safely add --no-sandbox --disable-setuid-sandbox --disable-dev-shm-usage etc. all the docker-specific flags. Thats what we do in https://github.com/ArchiveBox/ArchiveBox/blob/dev/Dockerfile...

[tamnd]

It should be fixed by https://github.com/tamnd/kage/pull/12

Thanks for nice trick.

[dimiprasakis]

Cool approach.

But, a compromise still lands on host's kernel, Docker doesn't provide kernel isolation (well it does on a macOS because it runs in Docker machine but thats a side effect).

I wonder if a better solution would be to play with seccomp or Linux capabilities so that Chrome is sandboxed even in Docker. Not sure how this would work tbh.

Answering here to get ideas, I saw your fix on Git and request for feedback (will try to review and give it some thought once I find some time)

[nikisweeting]

I have never seen anyone pull off seccomp nested sandboxing of Chrome in Docker before, if you manage to figure it out please let me know!