LWN: Comments on "Limiting the power of package installation in Debian"

... but he doesn't have root!

ghane — Wed, 28 Nov 2018 15:55:49 +0000

Read the mouseover alt text for more fun.

Rant

flussence — Wed, 21 Nov 2018 02:22:45 +0000

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

Limiting the power of package installation in Debian

laarmen — Tue, 20 Nov 2018 14:22:31 +0000

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

karkhaz — Tue, 20 Nov 2018 11:58:43 +0000

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

laarmen — Tue, 20 Nov 2018 11:24:22 +0000

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

berndp — Mon, 19 Nov 2018 21:03:31 +0000

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

berndp — Mon, 19 Nov 2018 20:55:58 +0000

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

rodgerd — Sun, 18 Nov 2018 22:43:27 +0000

> 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

mpr22 — Sun, 18 Nov 2018 16:15:50 +0000

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

jezuch — Sun, 18 Nov 2018 14:29:19 +0000

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

berndp — Sun, 18 Nov 2018 11:19:54 +0000

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

hvd — Sat, 17 Nov 2018 16:52:16 +0000

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

ssokolow — Sat, 17 Nov 2018 03:55:09 +0000

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

.deb vs .rpm differences?

ssokolow — Sat, 17 Nov 2018 03:46:53 +0000

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.

Limiting the power of package installation in Debian

HelloWorld — Thu, 15 Nov 2018 14:22:49 +0000

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

Rant

HelloWorld — Thu, 15 Nov 2018 14:03:38 +0000

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

Rant

gwg — Thu, 15 Nov 2018 05:12:49 +0000

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

Limiting the power of package installation in Debian

vadim — Mon, 12 Nov 2018 07:51:24 +0000

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.

.deb vs .rpm differences?

rweikusat2 — Fri, 09 Nov 2018 21:10:11 +0000

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.

.deb vs .rpm differences?

ceplm — Fri, 09 Nov 2018 16:07:43 +0000

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

Limiting the power of package installation in Debian

jccleaver — Fri, 09 Nov 2018 16:06:30 +0000

> 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

esmil — Fri, 09 Nov 2018 11:57:50 +0000

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

karkhaz — Fri, 09 Nov 2018 10:46:04 +0000

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

nilsmeyer — Fri, 09 Nov 2018 10:26:39 +0000

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

.deb vs .rpm differences?

guillemj — Fri, 09 Nov 2018 09:55:12 +0000

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

Rant

flussence — Fri, 09 Nov 2018 06:27:49 +0000

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

Limiting the power of package installation in Debian

flussence — Fri, 09 Nov 2018 06:23:42 +0000

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.

.deb vs .rpm differences?

Rudd-O — Fri, 09 Nov 2018 00:12:52 +0000

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.

Rant

NAR — Thu, 08 Nov 2018 21:24:13 +0000

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

Rant

rweikusat2 — Thu, 08 Nov 2018 20:36:31 +0000

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

Cyberax — Thu, 08 Nov 2018 18:42:33 +0000

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

Rant

jccleaver — Thu, 08 Nov 2018 18:40:43 +0000

> 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

Cyberax — Thu, 08 Nov 2018 18:03:07 +0000

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

jccleaver — Thu, 08 Nov 2018 16:24:35 +0000

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

Not just Debian

rweikusat2 — Thu, 08 Nov 2018 15:30:36 +0000

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.

I've seen the future and its the past.

rweikusat2 — Thu, 08 Nov 2018 15:05:17 +0000

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

drag — Thu, 08 Nov 2018 14:41:29 +0000

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.

Not just Debian

epithumia — Thu, 08 Nov 2018 14:31:41 +0000

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.

don't install .debs from untrusted sources?

anarcat — Thu, 08 Nov 2018 14:12:50 +0000

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.

Rant

raimue — Thu, 08 Nov 2018 13:18:37 +0000

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