Limiting the power of package installation in Debian

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.

Index entries for this article
Security	Distribution security

to post comments

.deb vs .rpm differences?

Posted Nov 7, 2018 18:42 UTC (Wed) by jccleaver (guest, #127418) [Link] (10 responses)

Forgive the newbie question here, but having spent the vast majority of my time in the RH ecosystem, are some of these "problems" caused by the nature of the format itself, or the tooling?

Any given RPM can have its entire file list exploded before install, and the scripts run are visible via a simple rpm -q --scripts -p <pkgname>. The file list includes the associated user/group and permissions ahead of time and could be examined for untrusted or unexpected entries.

An RPM scriptlet can call a script that the RPM itself lays down in %post, of course (and in fact, plenty of packages do that for things like data initialization or whatnot), but individual files can be extracted and examined ahead of time (using cpio) if there is a specific concern.

Some of these things sound a little interesting -- I could see value in write-protecting /boot maybe. I had thought an inotify for any non-t_tmp file not owned by the package being modified during %post could be flaggable, but I could also see that resulting in an endless prompt of Vista-esque UAC confirmations.

Ultimately, I guess I'm just a bit confused. A competent sysadmin has ways of examining an untrustworthy RPM, but the entire point of OSS (which GNU/Linux is an environment of) is that the person doing the work has methods for varying levels of introspection into what's going on, and it feels like the RPM format (and ecosystem of tools) provides mechanisms for that. Does dpkg and the .deb format not?

.deb vs .rpm differences?

Posted Nov 7, 2018 18:51 UTC (Wed) by zyga (subscriber, #81533) [Link]

Debian packages can certainly be treated in the exact same way. I think the point of the explored ideas is to make it harder for untrusted packages to attack the system. This will benefit unexperienced users and lazier administrators alike.

.deb vs .rpm differences?

Posted Nov 7, 2018 19:33 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

A Debian package is basically an ar archive containing two compressed tarfiles, control.tar.gz and data.tar.gz (possibly using a different compression method and corresponding extension). The second contains the complete filesystem tree of the package and the first the packaging meta-files. That's mostly a header with a general package description (called control) and the so-called package maintainer scripts which will be run at various phases of the install with certain arguments (as documented in the Debian Policy Manual).

Besides the option of disassembling the archive manually, the dpkg-deb command can be used to access the contents. Assuming a package file named uselessd_1.52.11_amd64.deb, the command

dpkg-deb --fsys-tarfile uselessd_1.52.11_amd64.deb | tar tvf -

would enable examining the contents of the data archive and

dpkg-deb -I uselessd_1.52.11_amd64.deb postinst

would extract the postinstall configuration script to stdout.

.deb vs .rpm differences?

Posted Nov 9, 2018 16:07 UTC (Fri) by ceplm (subscriber, #41334) [Link]

That's basically the same with RPMs (except it is cpio and not tar format, and you need and have a special tool rpm2cpio(8) instead of ar(1) for unpacking the package itself).

.deb vs .rpm differences?

Posted Nov 7, 2018 21:19 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

If some packages had labels guaranteeing freedom from certain kinds of risky behavior --- e.g. no code that will run as root --- that would make sysadmins' life easier. It also makes evaluating such packages much more feasible for normal users.

A sysadmin or normal user who would rather check a label than inspect package contents isn't necessarily "incompetent" or "lazy", they may just have better things to do with their time.

.deb vs .rpm differences?

Posted Nov 7, 2018 21:39 UTC (Wed) by jccleaver (guest, #127418) [Link]

> If some packages had labels guaranteeing freedom from certain kinds of risky behavior --- e.g. no code that will run as root --- that would make sysadmins' life easier. It also makes evaluating such packages much more feasible for normal users.

That seems like an impossible thing to guarantee in and of itself. File ownership, sure, but a general Linux system will be able intake config files in a number of ways that could involve root. You might as well try to guarantee against buffer overflows. Relying solely on install-time packaging tools for this (which would be a necessary component of this in order to provide any actual time savings for an admin) would be risky at best.

A better option might be to enforce MAC and flag packages that have any files installing in an unconfined domain onto the system. An included SELinux policy (required to do anything useful) in the package could then be scanned and presented in some sort of readable way for approval prior to manual install.

.deb vs .rpm differences?

Posted Nov 8, 2018 8:31 UTC (Thu) by mjthayer (guest, #39183) [Link] (1 responses)

Why such question marks over "switching to Flatpak"? Debian already supports it now and more and more third-party developers are providing Flatpaks instead of RPMs and debs. It is not intended for core infrastructure anyway: there would be nothing to change there. So most of the "switch" is already happening, and the question is at most whether a few things which Debian packages and which could fall into both categories (LibreOffice and other desktop applications) might benefit from being Flatpaks from the start.

.deb vs .rpm differences?

Posted Nov 17, 2018 3:46 UTC (Sat) by ssokolow (guest, #94568) [Link]

Flatpak is designed to be a desktop application packaging format, while .deb is designed to be powerful enough for distributing updates to core system functionality.

That's actually one of the advantages Snappy claims over Flatpak.

.deb vs .rpm differences?

Posted Nov 9, 2018 0:12 UTC (Fri) by Rudd-O (guest, #61155) [Link] (2 responses)

I like that I can rpm -qp --scripts and know what the install will run exactly, as root, on my system, prior to installation. You can't do that with debs. You have to explode the package and then look at the maintainer scripts one by one. That's cancer.

.deb vs .rpm differences?

Posted Nov 9, 2018 9:55 UTC (Fri) by guillemj (subscriber, #49706) [Link]

«dpkg-deb --ctrl-tarfile pkgname.deb | tar -xvOf-»

.deb vs .rpm differences?

Posted Nov 9, 2018 21:10 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link]

The dpkg-deb command can be used to do this.

dpkg-deb -I <package.deb>

prints a summary of the package content which lists all scripts. A

dpkg-deb -I <package.deb> <script name>

can be used to show each of them.

Limiting the power of package installation in Debian

Posted Nov 7, 2018 18:45 UTC (Wed) by Baughn (subscriber, #124425) [Link] (5 responses)

This is a problem that's entirely solved in NixOS.

Nix packages are built in a jail, and can *only* output a tree of files. That tree is merged with that of every other package in the profile, so you get the same bin/man/etc. directories as otherwise, but filename clashes are detected and can be handled appropriately. It isn't even possible to create a SUID binary this way; installing a package is, by itself, quite safe.

Packages that need to do system-wide configuration have to be built as NixOS modules, which could be an overlay, but this normally means they have to be packaged in the distribution's github repository -- which is far easier to contribute to than Debian. Any breakage usually happens at "compile-time" (for the OS, not the package), and in the event a non-malicious package broke your system, you can always roll back to the previous version.

Of course this all comes at a cost, but there are many, many benefits besides this one.

Limiting the power of package installation in Debian

Posted Nov 7, 2018 20:40 UTC (Wed) by atai (subscriber, #10977) [Link]

is this also present in GUIX?

Limiting the power of package installation in Debian

Posted Nov 8, 2018 10:55 UTC (Thu) by federico3 (guest, #101963) [Link] (1 responses)

> Nix packages are built in a jail, and can *only* output a tree of files

The ability to run scripts as root is not a bug, but a feature. Debian and RPM based distributions have been building the file tree and checking for collisions before installation since decades.
Yet, installing files is never going to be enough to integrate applications together. For example installing a plugin for a daemon that requires to run some kind of refresh command.

The use of such scripts is minimal for official packages and they are reviewed and vetted before upload.

Limiting the power of package installation in Debian

Posted Nov 15, 2018 14:22 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> Yet, installing files is never going to be enough to integrate applications together. For example installing a plugin for a daemon that requires to run some kind of refresh command.

Services are expected to be able to reload their configuration using the `systemctl reload` command. So packages could simply specify declaratively which services need to reload their configuration and then the package manager can do that. And it's better, because the package manager would only do this once per service, even if you install several such packages at once.

Limiting the power of package installation in Debian

Posted Nov 9, 2018 6:23 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

Ditto for Gentoo. It doesn't use a full jail, but builds are sandboxed from reading files outside of permitted paths; any naïve attempt to do so spews a very large error log and the build gets aborted. Usually that ends up tripping over buggy build systems that try to use ccache without permission.

The installation *can* run things as root after merging files, but any shady business will stick out like a sore thumb during code review, simply because needing to do so at all is so rare. It helps that things like messing with existing config and running services during package installation are culturally verboten.

Limiting the power of package installation in Debian

Posted Nov 17, 2018 16:52 UTC (Sat) by hvd (guest, #128680) [Link]

I have to disagree with the "ditto". "Any naïve attempt" is exactly right: Gentoo's sandbox is not a security feature, nor is it supposed to be. It is designed to catch mistakes, that's all. It can be trivially bypassed by malicious scripts, or sometimes -- rarely -- even by accident. That's different from Nix's jails: those are supposed to be (or become -- I do not know the current status) safe enough to run untrusted code in.

Limiting the power of package installation in Debian

Posted Nov 7, 2018 18:48 UTC (Wed) by zyga (subscriber, #81533) [Link]

One of the fantastic features of snapd is that the hook system runs various package hooks with the confinement and mount namespace applied. This means that while you may have install hook or refresh (aka update) hook as well as a configure hook (for package configuration system) all of those run as a confined root that can only write to package writable locations (e.g. $SNAP_DATA) and sees the filesystem the same way the applications stored in the package will at runtime. Hooks are also limited in execution time to some sane value (AFAIK ten minutes, at most) so that runaway package hook cannot bring down the system.

Scaling this idea to Debian is not going to be easy because of the huge surface area but I think that attempting to solve the problem is a valid and worthy goal to pursue.

Limiting the power of package installation in Debian

Posted Nov 8, 2018 5:29 UTC (Thu) by interalia (subscriber, #26615) [Link]

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

Yes, though it would be interesting if you could set these profile types in the APT source list, so that the tools could tell if you a package specified a profile other than the ones you have allowed. That way if the latest version of the Chromium 3rd-party package was profile "core" and I have it in my sources.list as "default" then APT/dpkg could decline to install it (or prompt).

It would not, as everyone agrees, prevent malicious changes, so I'm not sure the small gain (preventing/alerting of buggy/inadvertent changes) is worth the effort except if it prevents upload of the buggy packages in the first place.

Rant

Posted Nov 8, 2018 10:36 UTC (Thu) by NAR (subscriber, #1313) [Link] (14 responses)

I think the distribution model is somewhat outdated. It was great 20 years ago when the whole free software world fit on a single CD, they were written in C and disk space was at premium. Nowadays distributions just cannot cope with the huge amount of software out there. Debian has 20000 packages - this is about the same order of magnitude as the 8000 packages on hex.pm, but hex.pm hosts packages for niche languages Erlang and Elixir. PyPi has 157000 python packages, CPAN has 176000 perl modules, npm has 800000 JavaScript "building blocks" (that's 40 times the packages in Debian). Google Play has more than 3 million apps. It just doesn't scale a distribution to package everything, so it absolutely has to provide ways to install 3rd party packages. Also it's not feasible for the authors of these softwares to provide and maintain packages for various distributions in the official repositories of the distributions. They need not only generate the package, but be "part of the community" to be able to upload the packages to the official repository and it just won't happen.

LWN itself mentioned the "curl | sudo" pattern, which seems to get more and more popular. Essentially it's the same as Windows/OS X uses: download an .exe/.dmg and execute it, when prompted for password, type it. Even if the developers want to play nice and provide a .deb (or RPM) package, they provide it via their own repository, so they can release on their own schedule (which might be a lot faster or just simply different than the distribution's schedule). Also in single user desktops it doesn't really matter much if there's some code running as root - the important data is accessible by the user.

Rant

Posted Nov 8, 2018 12:58 UTC (Thu) by andrewsh (subscriber, #71043) [Link] (2 responses)

Debian currently has 84090 packages.

Rant

Posted Nov 15, 2018 14:03 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

Yeah, so it's not 40 times smaller than npm but only ~10 times.

Rant

Posted Nov 21, 2018 2:22 UTC (Wed) by flussence (guest, #85566) [Link]

Debian packages also tend to contain more than a single trivial function each. Comparing numbers blindly like this is a meaningless strawman.

Rant

Posted Nov 8, 2018 13:18 UTC (Thu) by raimue (subscriber, #95875) [Link] (2 responses)

Both the native Debian packaging and the upstream package indexes have their different purpose and are meant to co-exist.

Of course there is no Debian package for every single module available on PyPi, CPAN, etc. Only if you want to package software that needs a Python or Perl module, you also need a package for this module. This is a requirement to properly handle dependencies. Packaging the module and inclusion in the Debian repository ensures the required module (and especially exactly this tested version) will always be available through the lifetime of the Debian package. The list of the modules you will find in Debian will mostly be what other packages required and was packaged for this purpose.

Note that these Debian packages can often be generated automatically based on an upstream index such as PyPi or CPAN. https://wiki.debian.org/AutomaticPackagingTools

Rant

Posted Nov 8, 2018 14:41 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

A huge amount of software that is high quality with it's dependencies mapped out and so on and so forth will never, ever, be packaged by Debian. It's just not. It's not a issue of quality. It's a issue of time and man power.

As the FLOSS ecosystem increases in size it also increases in complexity and it also increases in speed. Both in terms of rate that software is written, but also in the rate of innovation. Now with dependencies it's not a issue of what makes software work within a OS, but what makes it worth within a organization or within a entire ecosystem.

Debian must operate under it's own time tables and follow it's own rules and unfortunately those time tables and rules rarely match up with anybody else's. With distribution's the software versions you can use is tied to the timetable set by that distribution's release strategy. A lot of the time it doesn't matter exactly what version of software you are using... Emacs latest release works about as well as a release from 2 years ago or 6 months ago. Same thing with compilers and terminals and whatnot.

But the same is not true for, say... Docker, kubespray, helm, vault, ansible, and cfssl. With tools like 'asdf' package manager (github.com/asdf-vm/asdf) I can install multiple versions of go, python, Erlang, and a half dozen other languages and their own language-specific package management systems and package versions.

I can use pipenv to setup different kinds of dependencies in a project, for example. I can setup dependency list for people who want to just run the software, but then I can setup a dependency list of pip packages for when you want to participate in the development process and their versions... and the versions of software needed to work with the CI pipeline or whatever.

And, sure, it's a mess and terrible and probably has lots of security deficiencies. But none of these things are tied specifically to your OS and your OS release versions like distribution packages are. And it works in pretty much any Linux distribution you want. And it works in OS X and most it mostly works in Windows. And the problems people are trying to address with these tools are unlikely to be addressed by any distribution-specific tool.

So not only you get the benefit of everybody using the software in any Linux distribution you also get the benefit of everybody using it in OS X and other operating systems. As these sort of tools gain in popularity the growth in change and innovation becomes almost exponential.

And while I see absolutely zero evidence to suggest that distributions and distribution packages are going away. (nor do I want them to go away... )What I do see is that distribution package management systems are increasingly relegated to simply setting up a base OS while other tools are used to manage most of the important software (from a perspective as a end user/developer/service provider) separate-but-on-top-of Linux distributions.

I've seen the future and its the past.

Posted Nov 8, 2018 15:05 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

What I do see is that distribution package management systems are increasingly relegated to simply setting up a base OS while other tools are used to manage most of the important software (from a perspective as a end user/developer/service provider) separate-but-on-top-of Linux distributions.

Not much change here: That's totally traditional "sysadminning" as it has been done since the 1980s (possibly even earlier).

Rant

Posted Nov 8, 2018 16:24 UTC (Thu) by jccleaver (guest, #127418) [Link] (6 responses)

> LWN itself mentioned the "curl | sudo" pattern, which seems to get more and more popular.

Anyone who runs "curl | sudo" deserves to have their root access taken away.

Rant

Posted Nov 8, 2018 18:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Why? This pattern is at least honest, as it shows you that you need to run some code as root. Debian packages do that sneakily.

Rant

Posted Nov 8, 2018 18:40 UTC (Thu) by jccleaver (guest, #127418) [Link] (3 responses)

> Debian packages do that sneakily.

If you think a .deb/.rpm package running a %post script is "sneaky", you might deserve to have your root access taken away too.

Rant

Posted Nov 8, 2018 18:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So how is "curl | sudo" different from adding a repository and doing "apt-get install"?

Rant

Posted Nov 8, 2018 20:36 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

This depends on how much the person who created the repository hates you and wants to hurt you. For the most general case, the package you're installing could just contain a script running curl | sudo as root.

Assuming an attempt was made to create sensible packages, one will have the usual benefits of using managed packages, eg, query which packages were installed, which files belong to which packages, update or remove installed packages easily, doing OS updates without "clean reinstalls" etc.

I've extensivley done both in the past and in my opinion, packages are a lot less of a hassle to deal with. YMMV. But it's worth a try.

Rant

Posted Nov 9, 2018 6:27 UTC (Fri) by flussence (guest, #85566) [Link]

>This depends on how much the person who created the repository hates you and wants to hurt you.

In practice it's usually repositories run by billionaire corporations like Microsoft, Google and Valve that are the most likely to hurt you. Repositories where it's an actual person's neck on the line usually have some semblance of QA.

Rant

Posted Nov 8, 2018 21:24 UTC (Thu) by NAR (subscriber, #1313) [Link]

On a single-user desktop it doesn't make much sense...

Rant

Posted Nov 15, 2018 5:12 UTC (Thu) by gwg (guest, #20811) [Link]

> It just doesn't scale a distribution to package everything, so it absolutely has to provide ways to install 3rd
> party packages.

3rd party application support has always been poor in Linux, due to the dominance of Distro's - hence the "year of the Linux desktop" has never arrived.

Here's a classic user application install problem: How does an app add permissions for a particular USB device that it provides support for ? Unlike (say) MSWindows or OS X there is no standard API for this, and root is needed to modify/add udev rules and in any case, udev rule file syntax/conventions is a moving target.

don't install .debs from untrusted sources?

Posted Nov 8, 2018 14:12 UTC (Thu) by anarcat (subscriber, #66354) [Link]

I take issue with this comment:

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.

That's not the reality of how software works out there. People *might* be able to run a vanilla Debian system without any third-party packages, but very often people are forced to install third party packages. In fact, we encourage that: don't we mock people who install software through curl | bash, pip, gem, or whatever? Don't we want all that stuff in Debian? For upstreams, this *will* mean providing their package as a PPA first, especially if they want to target users running stable. And those packages won't be vetter by a fellow Debian developer.

But even for those venerable package that go through the stations of the cross required to be bundled in the sacro-saint Debian archive, we do have a trust issue. Even as a Debian developper, I do not personally know every of the 600 Debian developer out there. I would like to *not* have to trust them.

And while some people might see this problem as a "wrong, non-achievable goal", I disagree. Many other distribution system out there, from flatpak to android APKs, are trying to solve exactly that problem. Why shouldn't we?

I know it's hard, but we have good targets we can work towards. I made a list, it's a start and I'm glad we're talking about it at least. Let's try to get there, at least.

Not just Debian

Posted Nov 8, 2018 14:31 UTC (Thu) by epithumia (subscriber, #23370) [Link] (1 responses)

This has long been a topic of discussion (and effort) in Fedora as well. I'm sure it's extended to other RPM-based distributions, too. There are multiple good reasons, including but certainly not limited to:

* All of the security issues highlighted in this article.

* In situations like Project Atomic scriptlets basically don't get run at all (because package installation doesn't happen on the machine which actually runs the installed packages) so alternate methods have to be used.

* Excessive complexity pushed to the packager that shouldn't be necessary.

* Scriptlets can introduce really unpleasant cyclical dependencies. Especially at install time, you may not be able to rely on being able to call the shell. RPM has an embedded Lua interpreter for this case, but that's even more complexity that the packager needs to care about.

* Scriptlets which modify existing data like configuration files are pretty scary in general.

Fedora has taken various steps to deal with scriptlets, including:

* Using the RPM "file trigger" system, to basically centralize scriptlets. This basically allows the package which "owns" a set of directories to provide scriptlets which are called when things are placed in those directories. So a package installing libraries no longer needs to care about calling ldconfig; the glibc package does that automatically.

* Providing macros for common scriptlets and generally offering means to hide scripetlets from packagers. This keeps packagers from needing to paste in random bits of shell code, and allows the macros to evolve or simply expand to nothing on releases where manual scriptlets are no longer needed.

* Providing single points of entry for important tasks which require scriptlets. So the scriptlet just calls a "do-something" executable instead of having a pile of shell. Which again allows the set of actions performed to evolve outside of the individual packages which need to perform them.

* Fixing upstream projects to accept "whatever.d" style configuration snippet directories so scriptlets aren't needed to modify the configuration of an existing setup.

Though it has taken some effort to get file triggers adopted in some of the very core packages like glibc (and is still not quite done for systemd services) the end result is that we've gone from having a whole pile of random mandatory scriptlets for various cases to... not nearly as many (but still a lot).

We would certainly like to get to a point where packages in the distribution simply don't have scriptlets. To the point that installing a package which does use scriptlets would be an exceptional act which could be flagged.

Not just Debian

Posted Nov 8, 2018 15:30 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

We would certainly like to get to a point where packages in the distribution simply don't have scriptlets. To the point that installing a package which does use scriptlets would be an exceptional act which could be flagged.

You will then end up in a state were upstream-sources will start to contain "global configuration scripts" of a few hundred lines of (obviously) Bourne shell code reconfiguring the system in prefectly arbitrary ways with prospective admin users being instructed to "just run that as root" after install (I've spent the better part of the last two weeks with packaging such a something for Debian/ Ubuntu) because

nobody wants to waste time on figuring out the finest details on how packaging for version X of distribution Z is supposed work, being perfectly aware of the fact that it will all have changed by the time version X + 3 is "current".
the set of use cases which happens to be useful to you is a subset of "the set of use cases"

IOW, that's going to be a let of churn in order to end up exactly where things stand today.

Limiting the power of package installation in Debian

Posted Nov 9, 2018 10:26 UTC (Fri) by nilsmeyer (guest, #122604) [Link] (12 responses)

I'd rather have a feature that prevents packages from auto-starting daemons ;)

Limiting the power of package installation in Debian

Posted Nov 9, 2018 10:46 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

On Arch Linux, this behaviour is default. If you would like to make it the default on your system, this section of the Arch wiki is useful: https://wiki.archlinux.org/index.php/Systemd#Enable_insta...

in short, run

# echo 'disable *' >> /etc/systemd/system-preset/99-default.preset

Limiting the power of package installation in Debian

Posted Nov 9, 2018 11:57 UTC (Fri) by esmil (subscriber, #82064) [Link]

It's not a feature that is much advertised, but this works in Debian:

echo 'exit 101' > /usr/sbin/policy-rc.d
chmod 755 /usr/sbin/policy-rc.d

Limiting the power of package installation in Debian

Posted Nov 9, 2018 16:06 UTC (Fri) by jccleaver (guest, #127418) [Link] (9 responses)

> I'd rather have a feature that prevents packages from auto-starting daemons ;)

FWIW, this has been the policy in RedHat/Fedora forever. See https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Why_d.......

Thanks to systemd making all sorts of scheisse technically a "service", there's a lot more that begins there, but even still an auto-starting-on-boot service needs to meet certain qualifications: https://fedoraproject.org/wiki/Packaging:DefaultServices

Either way, a service should *NEVER* be explicitly started up in a %post-RPM script, since you can't guarantee the situation you're installing in. For daemons, the most you do is a '/sbin/service <daemon> condrestart', which restarts it IFF it's already running.

Limiting the power of package installation in Debian

Posted Nov 18, 2018 11:19 UTC (Sun) by berndp (guest, #52035) [Link] (8 responses)

You really *never* *ever* want to start a daemon (or "service" or ...) automatically at boot time or after the installation because folks may want to install a package just to get to the manual pages and/or other documentation. Period.

And yes, security is the second reason (because folks may habe a daemon running without knowing it).

Limiting the power of package installation in Debian

Posted Nov 18, 2018 14:29 UTC (Sun) by jezuch (subscriber, #52988) [Link] (4 responses)

Debian's motto is (was?) "just apt install it" (or something like that), which means that no additional manual steps are needed bedsides installing, the thing is immediately ready to be used. You really think this is not the sensible approach? If you want just the documentation, just apt install the corresponding -doc package.

Limiting the power of package installation in Debian

Posted Nov 19, 2018 21:03 UTC (Mon) by berndp (guest, #52035) [Link] (3 responses)

That motto is insecure by design - obviously.
It may also sound/be installation person friendly which may make it easier to sell Debian as such.

In reality, that motto is good for the "don't care about security" faction as the stuff just runs (somehow ...).
But for the "I want to know what I do" faction, one has to stop the daemon immediately (or add some iptables rules beforehand) so that one can read and think about the configuration - let alone testing it.

Well, thank you for pointing out explicitly what folks can expect from Debian on a real server accessible to the real Internet ....

Limiting the power of package installation in Debian

Posted Nov 20, 2018 11:24 UTC (Tue) by laarmen (subscriber, #63948) [Link] (2 responses)

IIRC most daemons are started automatically but don't listen to the outside, only localhost. (I might be wrong though)

Security is not a black-and-white issue. One might think that having a daemon automatically configured with sensible settings for basic, domestic use (such as, well, listening to localhost only), so that the user doesn't have to do anything, is better than having them copy-paste instructions from a random webpage on the Internet.

Limiting the power of package installation in Debian

Posted Nov 20, 2018 11:58 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (1 responses)

I just had a look at the Debian openssh-server package, and it seems like it's open to the internet by default. (Though I don't have a Debian system to test on, so would be happy to be corrected either about that, or about the service being started upon installation).

If all of that is true, then I'd be especially concerned because the openssh-server package is pulled in by the ssh metapackage. It wouldn't surprise me if a new user, being asked to install SSH, took that to mean running `apt-get install ssh` and therefore inadvertently ended up with sshd connected to the internet when all they wanted was the client (openssh-client).

Anyway, if daemons are started automatically but only listen to localhost, then that still contradicts the "just apt-install it" motto, since you'll need to edit sshd.conf to do anything useful. If you're going to make the user do work, it's surely better to have a sane default sshd.conf and ask them to run `systemctl start sshd`, than to ask them to edit a text file and run the same command, except for s/start/restart?

Limiting the power of package installation in Debian

Posted Nov 20, 2018 14:22 UTC (Tue) by laarmen (subscriber, #63948) [Link]

sshd is different, as it cannot be useful without outside communication. There are few cases like that (Avahi and ntpd both come to mind). I'm with you with the apt install ssh scenario though.

I'm actually surprised, as Apache2 seems to listen to the outside by default (no fresh Debian at hand here though) even though there are relatively valid reasons to have a local-only web server. But in any cases, these are only examples, and I still think the policy of starting the services automatically with a sane default config is helpful for non-expert users, at the cost of a mild annoyance for the expert users.

Limiting the power of package installation in Debian

Posted Nov 18, 2018 16:15 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

Binary packages of daemons prepared by conscientious Linux distribution packagers are arranged like:

foobard Foobar daemon
foobard-doc Foobar daemon documentation

(with foobard encouraging but not compelling you to install foobard-doc).

If all you want is the doc, you can then simply install foobard-doc and now you have the documentation but not the daemon, so there is no possible way for the daemon to run because it isn't on your system.

Under that scheme, if foobard can be given a safe, sane default configuration for live systems, it's perfectly reasonable for the act of installing foobard through the package tool to also automatically start foobard.

(And yes, the first statement of this post is intended as a dogmatic assertion that any Linux distribution packager who prepares the binary package of a daemon and its documentation as a monolithic lump is by definition not sufficiently conscientious.)

Limiting the power of package installation in Debian

Posted Nov 19, 2018 20:55 UTC (Mon) by berndp (guest, #52035) [Link]

... if there a separate -doc package.
Many packages don't have that. Or install a server/daemon together with the client.

Limiting the power of package installation in Debian

Posted Nov 18, 2018 22:43 UTC (Sun) by rodgerd (guest, #58896) [Link]

> And yes, security is the second reason

Indeed. "Listen on an open port by default" was one of the many things that Windows was ruthlessly (and rightly) mocked for at the start of the century.

Limiting the power of package installation in Debian

Posted Nov 12, 2018 7:51 UTC (Mon) by vadim (subscriber, #35271) [Link] (2 responses)

Better package security is a good thing, but I think at this point making sure stuff doesn't run as root isn't of that much utility.

99.9% of what I care about runs under my own user account. Great, a package can't mess around with /etc/shadow, but on a personal laptop, who cares? A malicious program running under my own account can set LD_PRELOAD, create aliases, or just read files in $HOME to get credit card data out of my browser. And then it can open a socket and transmit that data anywhere.

Not allowing it root access isn't going to make things a whole lot better.

Limiting the power of package installation in Debian

Posted Nov 17, 2018 3:55 UTC (Sat) by ssokolow (guest, #94568) [Link]

Isolating individual desktop applications within a single user session is intentionally outside dpkg's scope and what Flatpak is intended to solve.

(In the same way that there's no rush to solve difficult problems in X11 when they're already slated to be solved by Wayland+XWayland.)

... but he doesn't have root!

Posted Nov 28, 2018 15:55 UTC (Wed) by ghane (guest, #1805) [Link]

https://xkcd.com/1200/

Read the mouseover alt text for more fun.