Improve sudo need

Right now the Tor Browser build takes a long time, and sudo is needed periodically throughout it. This means you have to either run it as root, babysit it, or set your user account up with passwordless sudo. All of those kinda stink.

It's be cool if we could improve that a bit. Ideas:

• Write a setuid program that execs the necessary commands but provides input and directory filtering (directory path either compiled in or read from a root-owned file I guess)
• Same idea but instead of setuid, it's set up to be run with passwordless sudo
• Somehow request sudo access in the beginning and retain it through the whole script (without running everything as root)

added component::applications/tor browser gitlab-tb-tor-browser-build owner::tbb-team priority::medium severity::normal status::new tbb-rbm type::enhancement labels

Trac:
Keywords: N/A deleted, tbb-rbm added

Doing the build as root is probably not a good idea as everything is run as root. At least with a user account set up with passwordless sudo, only the commands that need to be run as root are run as root.

It would be nice if it would be possible to do builds without giving full root access to the user, however it seems difficult to do in a way that really prevents the user from getting root access:

• the suid program (or sudo passwordless program) cannot be controlled by the user, so it needs to be manually setup by an admin, and manually updated each time we need to change it
• if the runc config.json file is controlled by the user, the user can change it in a way that makes it easy to escape the container as root, so the runc config.json needs to be setup and updated by an admin too
• the user is controlling the commands we run as root inside the container to install dependencies, so they could for instance do thing such as creating a suid file inside the container and execute it outside the container to get a root shell. And there are probably many other techniques someone with a root shell inside a container could use to get a root shell outside the container. We can probably harden the container configuration to prevent some of them to work, but I think it would be a lot of work to try to fix them all. And maybe not possible if we want to give the container the CAP_SYS_ADMIN capability, which we need to do in some of the containers to be able to use debootstrap to create the base images, so maybe this part too would need to be done by the suid wrapper installed by the admin.

Instead of doing our own suid program to start containers, we could use docker which can be configured to allow users in the docker group to run docker without using sudo. However docker has other problems (no support for i386 containers, no easy way to verify the image we downloaded, images not removed when we remove the tor-browser-build directory), and it doesn't really fix the problem as it has many options that can be used to create insecure containers: --pid=host, --cap-add=[], --privileged=true, etc ...

So I think it would be possible to do something that gives the impression that the user does not have full root access, but I'm not sure it is worth it if we can't effectively prevent the user from getting root access easily. I think requiring passwordless sudo at least makes it clear that the user can do anything on the machine.

I think an other option would be to use the user namespace (if available), which should allow us to create containers without requiring root access. I have not yet looked in details how to do that.

FWIW: There should be rootles containers available for a while now in runc (https://github.com/opencontainers/runc/pull/774). We could investigate that feature and check whether it is usable for us (I actually hope so as requiring root for building Tor Browser at some point is surely a hassle for some builders).

Trac:
Cc: boklm to boklm, pospeselr

It seems F-Droid does not like the sudo requirement either, see: https://gitlab.com/fdroid/fdroiddata/merge_requests/4676.

Trac:
Priority: Low to Medium

It seems that mmdebstrap, which we could use instead of debootstrap, has features to use a user namespace to create a chroot tarball, without root privileges: #31996 (moved).

Add magic gitlab keyword.

Trac:
Keywords: N/A deleted, gitlab-tb-tor-browser-build added

mentioned in issue #27539 (moved)

mentioned in issue #31996 (moved)

mentioned in issue #34122 (moved)

mentioned in issue #34176 (moved)

moved to tpo/applications/tor-browser-build#23631 (closed)

mentioned in issue tpo/applications/tor-browser-build#31996 (closed)