7

If I understand correctly, the maintainer scripts in Debian packages are executed with root privileges. I assume that this means that, contrary to my expectation, installing a malicious package can not only lead to compromising the user that runs code in the package, but the whole system.

Question 0: Am I correct?

Question 1: Are there any ways to mitigate this threat? (For example, is there any tool that would install Debian packages in a chroot-like "sandbox" alerting the administrator if postinstall script attempts to use potentially problematic privileges.)

Question 2: What are the ways in which Debian team addresses this threat in the main repositories? Given the sheer number of people who contribute packages to those repositories, it must be a non-trivial task.

(Same questions apply to derivatives of Debian, such as Ubuntu. Information on how other distributions handle this issue is also welcome.)

Added on 27 July 2015: I can summarize the received answers can as follows:

0) Yes, it is a problem.

1) Read the code, and/or install software as user who intends to use it. For later, there is fakechroot tool that might ease the pain of installing manually.

2) There is no particular attention paid to this problem beyond normal screening of the Debian repositories by the many volunteers involved.

I will now accept WhiteWinterWolf's answer, but I remain interested in a good solution to this problem. Also, if other distributions handle this better/differently, it'd also be interesting.

Improve this question
6
  • I don't know enough to fully answer your question, but I can say that question zero is true. Packages, like all software / software updates, need to be screened before use to prevent the system from being compromised.
    – etherealflux
    Commented Jul 24, 2015 at 14:40
  • @etherealflux Of course, they need to be screened. The point of my question is that the installation process poses more threat than it needs to. 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. One can easily imagine scenarios when user asks admin to install some software for them only to...
    – Boris Bukh
    Commented Jul 24, 2015 at 14:46
  • @BorisBukh Well, the reason it's root is actually kind of obvious from a security standpoint; it needs to not be a regular user. If it were a regular user, than whatever regular user on the system could modify the package and pwn the system that way. Now, that leads to the issue of the user doing the installs being root; unfortunately, a package install needs to be able to do (essentially) anything because a package could be anything- from a kernel patch to a tetris game.
    – Parthian Shot
    Commented Jul 24, 2015 at 15:19
  • Unfortunately that also means it can modify other packages, and to fix that you'd need to have a separate user account for each package. I suppose what you'd need is a special 'install' user who is essentially nobody, and can be granted permissions for the duration of an install run. Then the package maintainer figures out what permissions their package requires, 'install' runs the install with those permissions, has them revoked post-install, and then all the files' are switched from install:install ownership to root:wheel ownership.
    – Parthian Shot
    Commented Jul 24, 2015 at 15:22
  • ...Or something like that. I agree it's non-ideal, but I suppose the current perspective is "if they can run code on your system, they can own your box" so once malware gets to the installation step, it's game over, man. Game over.
    – Parthian Shot
    Commented Jul 24, 2015 at 15:24

1 Answer 1

Reset to default
6

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:

  1. Download the Tetris game source code,
  2. 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.
  3. 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.

Improve this answer
4
  • Thanks for the answer. While it is good in theory, I do not think that the second part is a "solution" to the problem in practice for most of us. In the places that I have been, users usually lack the technical expertise to do download source/track dependencies/compile/swear/track more dependencies thing that you describe. When they do it, most still want to avoid this big hassle. Hence, facing user complaints, lack of time, some admins give into the temptation of using the less-secure, but simpler options of "just install the package from non-free". I'll accept your answer if no other comes.
    – Boris Bukh
    Commented Jul 24, 2015 at 19:18
  • As I said it all depends upon actual needs and environment (and audience!). There is also another very simple solution: a Virtual Machine for each one and everyone can be root in his VM without interfering with other people. But this solution seems out of scope of a traditional multi-user Unix-Debian environment. Granted that most Linux distro are binary-packages oriented so compiling from source may seem daunting for non technical people, BSD world on the contrary being source-packages based there are a lot of facilities there missing in Linux to make it more natural but its another world :).
    – WhiteWinterWolf
    Commented Jul 24, 2015 at 19:52
  • @BorisBukh: I crossed this post from ServerFault which may interest you. As per my quick overview, it may contain interesting solutions like fakechroot, PortableLinuxApps (ex. Klik) and Linuxbrew. If one of these matched your needs, do not hesitate to put your feedback here as a new answer ;) !
    – WhiteWinterWolf
    Commented Jul 25, 2015 at 13:58
  • 1
    Since you've already written a book chapter on the topic I won't put up another answer, but users can also turn to pdos.csail.mit.edu/mbox/ to easily install and test a package as a non-root user, and/or to inspect how it impacts the underlying filesystem.
    – Steve Dodier-Lazaro
    Commented Aug 6, 2015 at 12:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .