Gitpod: Root/sudo permission

Created on 30 Aug 2018  Â·  20Comments  Â·  Source: gitpod-io/gitpod

Just a question, I'm trying to execute some selenium tests, I was trying to add chrome but looks like the user is not sudo in the container.

enhancement

Most helpful comment

Note: Using sudo is sometimes necessary (e.g. to install a missing tool or package), and having to create a different workspace from a new Docker image is a bit painful.

It might be worth revisiting these security reasons, as in older Docker versions, root was able to escape containers on to the host, but that was fixed a few years ago and is no longer true in recent Docker versions.

Over at https://janitor.technology, we allow users to sudo in their containers, because we believe that with a recent Docker (using the default seccomp profile that blocks dangerous syscalls and capabilities) it's "safe enough" for sudo.

Also note: Our project images are all based on janitortechnology/ubuntu-dev, which includes a user with password-less sudo capabilities.

EDIT: What I say is true for Docker, but I'm not sure if it applies to Kubernetes (especially since I seem to remember that they disable seccomp by default, or used to).

All 20 comments

Yes, at runtime the workspace container runs without sudo or root for security reasons.
But you can install any tools in custom Docker image and set it in your .gitpod file.
That is during Docker build you can be root, but at runtime not.
More information here: https://www.gitpod.io/docs/config-docker/

Note: Using sudo is sometimes necessary (e.g. to install a missing tool or package), and having to create a different workspace from a new Docker image is a bit painful.

It might be worth revisiting these security reasons, as in older Docker versions, root was able to escape containers on to the host, but that was fixed a few years ago and is no longer true in recent Docker versions.

Over at https://janitor.technology, we allow users to sudo in their containers, because we believe that with a recent Docker (using the default seccomp profile that blocks dangerous syscalls and capabilities) it's "safe enough" for sudo.

Also note: Our project images are all based on janitortechnology/ubuntu-dev, which includes a user with password-less sudo capabilities.

EDIT: What I say is true for Docker, but I'm not sure if it applies to Kubernetes (especially since I seem to remember that they disable seccomp by default, or used to).

It might be worth revisiting these security reasons, as in older Docker versions, root was able to escape containers on to the host, but that was fixed a few years ago and is no longer true in recent Docker versions.

Do you have a reference for this claim? We are waiting for a recent Docker change to land in Kubernetes.

Do you have a reference for this claim? We are waiting for a recent Docker change to land in Kubernetes.

Sorry, I don't have a solid reference for this, and looking around I see that most of the security best practices for Docker and Kubernetes still mention restricting root access as a good idea.

From my understanding this is a "defense in depth" thing. Today I don't think that there are obvious ways to use sudo to escape a container (with a recent Docker on a recent kernel), but historically escapes may have been easier to achieve with sudo than without (e.g. using kernel exploits; forcing namespace changes; chrooting to a host directory; etc).

Nowadays, "root" privileges are segmented into capabilities (which can be granted or not using a seccomp profile, in order to enable valid use cases while preventing dangerous exploits), and modern Linux namespaces effectively segregate users and resources inside a container from host-level stuff, but I'm by no means a security expert and maybe it's still too risky to allow sudo inside containers.

We definitely want to and will allow sudo at runtime. But as mentioned earlier we are awaiting some announced changes in the technologies we use.
At the same we will make it easier configure a custom workspace with the tools you need, so you don't need to add additional things at runtime.

Until https://github.com/kubernetes/kubernetes/pull/64005 has landed we could consider whitelisting certain trusted users to allow sudo/root.

Worth noting that there are multiple upstream approaches to this: https://github.com/kubernetes/enhancements/issues/127 tracks all potential PRs for it

Thanks @stuartpb. We're watching that thread closely for 1,5 years now, but:

  1. it's from 2016
  2. it always gets delayed, without any code being merged.
  3. it seems nobody is working on it ATM

It seems like the general trend is to push the problem to the container runtime.

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Get this error on installling certain ruby version with rvm. Guess this IDE is not for me yet.

Nvm. Fixed with customization on Dockerfile.

@kevinhq What was the problem in the end, i.e. what was the customization you did?

Relevant: https://github.com/docker/compose/issues/7244#issuecomment-625834398

Development of rootless docker

sudo isn't needed since we can install everything through dockerfile

@kevinhq No we can't

Is the rootless version coming at some point? It sounds somewhat useless without apt.

Is the rootless version coming at some point?

Yes, it’s on the roadmap, although I can’t tell you when it will be released. Probably ‘sudo’ first at some point (allowing ‘sudo apt-get’ in workspace terminal, but still restricted by Docker’s default security model), and later rootless Docker cluster (allowing truly privileged containers with more capabilities).

It sounds somewhat useless without apt.

You can already use ‘sudo apt-get’ in Gitpod like this: https://github.com/nushell/nushell/blob/master/.gitpod.Dockerfile

You can also use ‘brew install’ directly in a Gitpod terminal (no ‘sudo’ needed).

FWIW i am working on Proof-of-concept for gitpod to switch on VM-based containers which so far looks more economical and doesn't have this restriction + Allows VM support (also makes us to use other kernels)

Still needs some testing and security research..

You can also use ‘brew install’ directly in a Gitpod terminal (no ‘sudo’ needed).

You can also use rootless apt which creates a new environment in your /home directory and adds the executables in PATH, i have janky implementation for this which i plan to implement if VM-based containers fails.

FYI, we're doing a YouTube livestream about this feature in about ~2.5 hours: https://www.youtube.com/watch?v=l4I2TVAnBuw

Will a recorded video be available later?

@dclong Yes, with the livestream concluded, the link above is now a regular YouTube video.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Kreyren picture Kreyren  Â·  3Comments

tekumara picture tekumara  Â·  3Comments

LezaiNiubi picture LezaiNiubi  Â·  3Comments

Kreyren picture Kreyren  Â·  3Comments

kittaakos picture kittaakos  Â·  3Comments