Limiting the power of package installation in Debian


LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Jake Edge
November 7, 2018

There is always at least a small risk when installing a package for a distribution. By its very nature, package installation is an invasive process; some packages require the ability to make radical changes to the system—changes that users surely would not want other packages to take advantage of. Packages that are made available by distributions are vetted for problems of this sort, though, of course, mistakes can be made. Third-party packages are an even bigger potential problem because they lack this vetting, as was discussed in early October on the debian-devel mailing list. Solutions in this area are not particularly easy, however.

Lars Wirzenius brought up the problem: "when a .deb package is installed, upgraded, or removed, the maintainer scripts are run as root and can thus do anything." Maintainer scripts are included in a .deb file to be run before and after installation or removal. As he noted, maintainer scripts for third-party packages (e.g. Skype, Chrome) sometimes add entries to the lists of package sources and signing keys; they do so in order to get security updates to their packages safely, but it may still be surprising or unwanted. Even simple mistakes made in Debian-released packages might contain unwelcome surprises of various sorts.

He suggested that there could be a set of "profiles" that describe the kinds of changes that might be made by a package installation. He gave a few different examples, such as a "default" profile that only allowed file installation in /usr, a "kernel" profile that can install in /boot and trigger rebuilds of the initramfs, or "core" that can do anything. Packages would then declare which profile they required. The dpkg command could arrange that package's install scripts could only make the kinds of changes allowed by its profile. Mostly, he wanted to spark some discussion:

This is a quick thought, while I was trodding in the dark, wet, cold evening to the grocery store. It's not a full specification, and it may well not solve all problems that may happen when installing a broken or malicious .deb. I'd like for us to solve at least the more glaring problems, rather than throw our hands up and say it's [too] difficult a problem. I'd like to be safe from my own mistakes, and if that means our users are more safe and secure as well, that's a good thing.

As Paul Wise pointed out, though, maintainer scripts are not the only problem. There are lots of ways ("setuid binaries, cron jobs, systemd units, apt keyring information, sudoers files and so on") that a malicious package could compromise the system. He pointed to a wiki page created by Antoine Beaupré to document the problem of untrusted .deb files along with some possible solutions. Wise suggested that Flatpak might also provide part of the solution.

Beaupré agreed that there are numerous problem areas in the current installation mechanism. He would like to see Debian look at fixing some of them, even if it doesn't lead to fixing them all:

Yes, there are a billion things that could go wrong in the current approach, but if we had *some* safety net, controlled in the sources.list file, we could at least restrict what third-party packages would do.

For example, there's no reason why a package like Chromium should be able to run stuff as root. The vast majority of third-party repositories out there mostly ship this one binary that does not require special privileges other than installing stuff in /usr, without suid or any special permissions.

He suggested some low-hanging fruit, like changing maintainer scripts to use a declarative syntax rather than be open-ended shell scripts. Switching Debian to use Flatpak, which wasn't quite what Wise meant, "would be a rather controversial change", but the Flatpak project is working to address many of the problems under discussion, so it may make sense to look at it in more detail, Beaupré said.

Protecting against malicious .deb files is too high of a hurdle to realistically clear, according to several in the thread. W. Martin Borgert said:

However, I would not try to see this work too much as means of defense against malicious deb packages. This leads to a wrong, non-achievable goal. I see it as a means to provide better quality, predictable system state, and safety against bugs.

Ralf Treinen concurred with that, but noted that it is difficult to know if a script is doing something that it shouldn't. "Having a declaration of what the maintainer thinks are the possible effects of a script would certainly help us." But Guillem Jover rejected the whole idea of ever securely installing untrusted .deb files: "If you do not trust the .deb, then you should not be even installing it using dpkg, less running it unconfined, as its paradigm is based on fully trusting the .debs, on using shared resources, and on system integration." He went on to list multiple areas that would need attention, concluding that if all of those things were fixed, it wouldn't be much like today's packages "except for the container format. :)".

While protecting against malicious packages may not really be in the cards for .deb files, Flatpak (or other, similar ideas such as Ubuntu's .snap packages) may eventually provide some of that kind of protection. That is not really something that Debian can control; users have shown that they want various third-party tools and the makers of those tools are going to do what they think they need to do in terms of installation. If Debian gets in the way of that, it is likely to lead to it becoming less relevant.

The way that packages are built and maintained for Debian is already complicated enough, Tomas Pospisek said: "I think Linux systems per se, Debian as a runtime, the (social) processes required from DDs/DMs, the whole technical Debian packaging ecosystem are each plenty complex enough already." Adding to that will just make it "less fun" leading to fewer Debian Developers and Maintainers (DDs/DMs), less software being packaged, and, ultimately, fewer users.

There is appeal to protecting packagers and users from silly errors; as Paride Legovini put it: "I know I won't screw up anybody's system with a font package as I restricted it to /usr/share and /etc/fonts." But the problem with things like Chrome and Skype that Wirzenius started out with is not really amenable to the (not fully baked) solution he described. Profiles might help Debian package maintainers, but are not likely to help with third-party packages. Legovini continued:

But I don't think it would solve the problem you pose. Who is going to set the profile? If if is the 3rd party packager, they will just use 'core' and install their APT source (or whatever they want). If it can be specified or overridden by the user at install time, then trying to install Skype with ‑‑profile=default will make the installation fail, and the user will just resort to ‑‑profile=core.

Some kind of declarative system for package installation is one solution that could help. Packages could only perform the actions allowed by the package manager—not arbitrary shell commands. Simon Richter described what that might look like in some detail. Wise also pointed out that the dpkg maintainers do have declarative packaging "on their radar".

No grand conclusions came from the discussion, but that is partly because there were several different aspects under consideration. Preventing Debian packagers from inadvertently causing installation errors is a much more tractable problem than trying to prevent malicious .deb files from wreaking havoc. And non-malicious third-party packages, though possibly buggy or taking undue liberties, are yet again a somewhat different problem. The problem is not limited to Debian either, of course; package installation on any distribution is likely to suffer from most of the same problems. It is good to see discussion in this area, if only to keep it in mind as packaging evolves down the road.

(Log in to post comments)