Opened 17 months ago

Last modified 7 months ago

#23631 new enhancement

Improve sudo need

Reported by: tom Owned by: tbb-team
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm
Cc: boklm, pospeselr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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)

Child Tickets

Change History (4)

comment:1 Changed 17 months ago by gk

Keywords: tbb-rbm added

comment:2 Changed 17 months ago by boklm

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.

comment:3 Changed 17 months ago by boklm

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.

comment:4 Changed 7 months ago by gk

Cc: pospeselr added

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).

Note: See TracTickets for help on using tickets.