Question 0: Am I correct?
Yes you are correct. Installing a package requires root privilege, so installing a malicious package means running malicious code as root.
Question 2: What are the ways in which Debian team addresses this threat in the main repositories?
First, you are recommended to use only Debian repository, and more precisely Debian stable repositories, this for two reasons:
- The code from this repository has been screened by a lot of people before entering this stable branch which will by far limit the possibilities of a malicious application stepping through.
- Then only security updates are provided, so future updates size are by far smaller than updates which would add dozens of shiny new features. Such modification being smaller, they are more easily screenable which, again, limits the possibility of anything malicious stepping through.
Then, once your root process is about to initiate the installation of the package, in order to ensure that this package is really the one provided by Debian team and has not been altered by a third party, each packages are cryptographically signed. Any change in the package will result in a bunch of warnings messages which will ask you to think twice before proceeding with this installation.
Question 1: Are there any ways to mitigate this threat?
Now for what concerns your side, it mainly depends on your actual needs and environment.
Of course as etherealflux mentioned in his comment any new installation on a production system should be carefully screened. You may want to manually unpack the package to check its content, you may want to install it in an isolated test environment to check its behaviour, etc.
However, there is also another solution, mainly addressing your own comment "There is no reason that installing, for example, a tetris game on a communal machine should endanger accounts of users who do not play the said game.".
But for this, we need to step back a bit to understand what packages actually are.
In the early Unix/Linux days, there were no packages (or at least very few in the case of Linux): every one wanting to install an application should first download the source, then compile them. This made software installation and update take longer, but allowed each one to configure the software precisely how they wanted to.
Then packages came: pre-compiled software with most common settings for such system.
Here lies your issue with the Tetris game: these "most common settings" include, among over thing that the software will be installed system-wide, and this is this system-wide installation by default which is the reason why a user installing a Tetris could endanger the whole shared environment and all its users.
Software installation at the user level
As long as your
/home partition (if it is a separate one) allows code execution (no
noexec mount option in the
/etc/fstab file), then your users are allowed to install their own software in their own home directory, without affecting the other user and without requiring root privileges.
However, such installation is not part of the "most common setting" mentioned above, therefore the packages do not offer this possibility. Your user therefore has to proceed as follows:
- Download the Tetris game source code,
- Read the
INSTALL documentation file and check compilations options allowed by the
configure script (
./configure --help), both provided with the source code. More specifically, they will need to set all directories to be under their home dir. For instance, the script could allow a
--prefix parameter allowing to easily tell where the software will have to be installed, so you could for instance tell
./configure --prefix=/home/myuser/local. But other software may require different parameters to be set depending on their complexity and requirements. With a good and sane project, all this is clearly explained in the provided
INSTALL file and
configure online help and is easier than it may seem.
- Afterwards, all it remains is to execute
make, take a break, and once the compilation has ended
make install (without sudoing to root!).
The only real issue in such process is if this software compilation requires dependencies not available on the system (this will result in an error message at the
configure step, one of the roles of this script being to ensure that all dependencies required to compile and run the software are met). This becomes a recursive issue since you have the choice between installing a package to satisfy the dependency, on compile it at the user level and set the appropriate
configure parameters / environment variable so the compilations tools and final binary will find all it needs.
But at last, your user will get a working Tetris fully installed on his account, without affecting the other user and without requiring any super-user privilege.