Limiting the power of package installation in Debian

by l2dy • 8 years ago

67 57 8 years ago

perlgeek• 8 years ago

I'd love it if some more common things that are done in postint scripts could be done in a declarative way, like adding system users.

And then there are things that are declarative in the debian/ dir (like auto-(re)starting the installed services) that end up as generated, procedural code in the postinst script.

When such things can be done in a declarative manner, it's much easier to reason about them programmatically, and maybe you could completely disable postinst scripts for a whole category of packages.

brazzledazzle• 8 years ago

When I first learned how Debian (and other) packages were put together I was somewhat surprised. Not just by the security implications but also by the inherent complexity. Even if you’re using templates and generators you can gain a lot by moving all of that out of the package and into the package manager/installer. Distribution-level changes, user OS customization and possibly even reduced privileges would become easier to handle. On the package manager side it seems like maintainability would (in the general case) vastly increase.

bluGill2• 8 years ago

There is a downside though: if you forget something in the declarative tool it cannot be done. Using bash scripts lets a good programmer get what they need done. Using declarative makes it easier to do everything we thought of but some things are accidentally impossible.

I think an escape to bash might always be required, but I think it should be a restrictive thing. That is packages with that flag require a special flag passed to dpkg. Also any packages using bash should automatically get extra reviewers.

mnw21cam• 8 years ago

I agree. I would imagine that the vast majority of packages could easily be marked as "doesn't run anything as root, doesn't install any SUID executables", with enforcement from APT. This then reduces the attack/bug surface to those packages that do need to do dangerous things.

JdeBP• 8 years ago

I addressed this in my packages with a roughly declarative language that turned into shell functions in a Debian, Arch, or FreeBSD package (by dint of prefixing with a shell function library) and into the packing list format for OpenBSD (by dint of an awk script). Examples:

    # dedicated user accounts
    file_owning_user "cron" "/var/spool/cron"
    directory "cron" "/var/spool/cron" "0755"
    directory "cron" "/var/spool/cron/tmp" "0700"
    directory "cron" "/var/spool/cron/crontabs" "0700"
    # bcron services
    service_with_dedicated_logger "bcron-start"
    service_with_dedicated_logger "bcron-update"
    socket_with_dedicated_logger "bcron-spool"
    # user-mode TTYs
    user_tty "vc1-tty"
    user_tty "vc2-tty"
    user_tty "vc3-tty"
    service_with_dedicated_logger "terminal-emulator@vc1"
    service_with_dedicated_logger "terminal-emulator@vc2"
    service_with_dedicated_logger "terminal-emulator@vc3"
    login_service_with_dedicated_logger "vc1-tty"
    login_service_with_dedicated_logger "vc2-tty"
    login_service_with_dedicated_logger "vc3-tty"
    # TTY ancillaries
    service_with_dedicated_logger "console-input-method@head0"
    service_with_dedicated_logger "console-multiplexor@head0"
    service_with_dedicated_logger "console-fb-realizer@head0"

There are different shell function mappings for pre/post-install/remove/update, making what (say) "login_service_with_dedicated_logger" does vary according to the action being taken and whether the package is a "tools" package or a "run" package. In the post-install of a "tools" package it creates dedicated user accounts and log file directories. In the post-install of a "run" package it conditionally enables and starts services.

It still needed the ability to run general-purpose commands here and there, especially to perform tidying up as things were renamed and errors were corrected over the years, and the number of declarative verbs that one turns out to need in practice is quite large.

frumiousirc• 8 years ago

I've used Debian since 1994 and can't recall a single package installation or removal which exhibited any problem this discussion claims to be solving.

numbsafari• 8 years ago

Yes, but we now live in a world of weaponized package takovers, such as the Kite incident with IDE plugins, or the security mishaps that have afflicted npm. The “I’m a good guy, you’re a good guy, we’re all good guys” approach doesn’t really cut it any longer.

stephenr• 8 years ago

I'm unfamiliar with 'the Kite incident' but the NPM incidents have been due to

a) the ass-backwards approach the company took to building a package manager.

b) the new development paradigm of "fuck it, find a library". Flying Spaghetti monster forbid these hipster developers actually have to write some fucking code themselves, its easier just to duct-tape together 200 different 'libraries', half of which do what you could do in 5 lines or less, and produces a dependency tree like fucking crab grass.

scbrg• 8 years ago

Packages in the official Debian archives are generally well behaved. Unofficial packages, sometimes less so. There was an incident a couple of months ago where a package (from Microsoft, incidentally) replaced your /bin/sh with bash. Wouldn't it be neat if such an atrocity wasn't possible?

isostatic2• 8 years ago

But you'd spot that when you look at the package before you install it.

rlpb• 8 years ago

"Unofficial packages" aren't really in the set of supported dpkg use cases. They're a hack that fail in the general case because there are various things they can't express because the expression of them comes from the other side of the package relationship (eg. Breaks/Replaces), and official packages don't declare such things for packages outside the Debian archive. Therefore external packages are fundamentally broken, but third parties keep using them because better alternatives haven't existed in the past.

Wouldn't it be neat if such an atrocity wasn't possible?

An easier way might be to make it difficult for users to install "unofficial packages", but that would be against the philosophy of users having ultimate control over their systems.

Your suggestion puts us in the rather interesting situation that you're requesting a new feature for something that primarily affects third party packages that aren't actually supported in the first place.

jankotek• 8 years ago

And I experienced hundreds of problems. It really depends on what you are doing.

isostatic2• 8 years ago

I build many small pacakges and have made a few postinst files which occasionally break and leave apt in an upset state, typically when auto-installed by the preseed while trying to do horrible things to files (like editing snmpd.conf). These aren't packages that follow the guidelines though, they're just internal ones I build for a small number of installs, and only ends up with an unconfigured pacakge. I've never seen an external package that accidently causes problems.

Postinsts and other control files should on the whole be really simple.

This post seems to be more about protecting users from accidental problems with package installation scripts, but not about deliberate problems with packages, nor accidental problems with packages post installation script.

When I take an untrusted .deb, I look inside at the files it's dumping out, and the scripts it's going to run. Making apt more declarative wouldn't stop that.

always_good• 8 years ago

Well, one problem is that apt-get's uninstall doesn't undo everything that could have happened during install.

It's just like how you need software like Revo Uninstaller on Windows to actually clean up everything: why?

It might not cause you day-to-day problems, but it's a massive defect in my eyes.

IronBacon• 8 years ago

I don't have the link at hand but a few years ago (so I'm probably wrong about the details) I think a Debian developer was annoyed by the misuse of his personal repository that he modified his deb packages to change the user desktop background, mostly to demonstrate that installing random unknown packages from the Interweb could be dangerous.

I recall that episode made some noise at the time...

heinrichhartman4• 8 years ago

I don't get why we would want to allow packages to run any scripts before/after the installation. I get why it's necessary at this point, but the true solution should get away without executing any code.

IMHO, a package should deliver a set of files to certain directories. That's it.

It should not overwrite existing files, that were installed by other packages. It should not change existing files in any way.

It might advise the system to trigger certain reindexing actions (systemd daemon reolad, update man-db, etc.) but doing this should be the duty of the package manager, not the package itself.

AFAIK, nix and Solaris' pkg are pretty close to this ideal.

A big advantage that this has, on top of security, is that:

- packages can be uninstalled safely and without side-effects

- package contents can be inspected (pkg contents)

- corrupted installations can be detected using checksums (pkg fix)

- package updates/installs can be rolled back using file system snapshots.

dTal2• 8 years ago

Because the scope of 'certain reindexing actions' is potentially unbounded. Suppose you have a large piece of software that uses plugins, which it finds by reading a 'plugins.xml' file. Now, when you install a plugin from the package manager, you need to modify 'plugins.xml' in some arbitrary fashion. You simply cannot constrain the entire software world to operate in a file-oriented, declarative manner.

jjnoakes• 8 years ago

You simply cannot constrain the entire software world to operate in a file-oriented, declarative manner.

You can, if the community wants to go in that direction.

Ideally the software which loads "plugins.xml" is updated to support a conf.d-like directory full of "plugin-pkg1.xml" through "plugin-pkgN.xml", each owned by separate packages. Many OSS projects have done this.

If that's not possible (closed-source, too much work, whatever) then it seems simple enough to build a separate XML-merging tool that the package manager invokes which combines the separate XML files during package installation.

simion3142• 8 years ago

How would you solve a task like creating an user group or things that are more complicated then dropping some files on the disk?

heinrichhartman4• 8 years ago

Adding new systemd service, for example just requires me to put a file into `/etc/systemd/system`. Many other applications work like this as well: Apache configs, /etc/sudoers.d on Debian, more examples in `/etc/?.d`

It's generally a good practice to make your system open for extension but closed to modifications [1].

There is no reason, the user database can not work the same way. Just have the system scan `/etc/passwd.d/*` on boot/reload and drop files there.

[1] https://drive.google.com/file/d/0BwhCYaYDn8EgODUxZTJhOWEtMTZ...

toast0• 8 years ago

User management could be handled as part of the package metadata, rather than an install script.

Schema migrations would still need a script or something though.

nine_k2• 8 years ago

Running arbitrary code may be needed if you want to upgrade an existing installation in-place. Imagine that you are upgrading to a new major version and want to migrate the existing configuration to a new format.

This need not be an automatic action, though; you might choose to postpone the migration, and offer a separate tool for the user to run.

This prevents any packages from depending on such a package, though: they can no longer be automatically installed, because their dependency cannot, too.

This changes the concept of package management seriously enough.

gronne3• 8 years ago

Easy, implement the config upgrade in the software (launcher) itself. 1. check config version on launch. 2. if old version upgrade.

heinrichhartman4• 8 years ago

Well, for me this is a question who owns the config file:

* If the package owns the file, and the user is not supposed to make changes to it, then package updates may do whatever to the file on update. It's good practice though, to leave a copy of the old file in /lost+found.

* If the user is allowed to make modification, then the user owns it. The configuration syntax becomes and API and should be treated as such. Breaking changes should be rare, preceded by a deprecation period and announced as major versions. As you say, it's questionable if such updates can/should be automated.

hodgesrm• 8 years ago

Your suggestion only seems to work if the software in the package is stateless. In the case of a DBMS the approach would just put data upgrade problems in another place and in some cases make them harder to solve as well.

heinrichhartman4• 8 years ago

State is a different problem. Usually programs don't mutate their executables.

Mutable, persistent state is usually put under /var and is user-owned. Package updates should not touch data in there.

srcmap• 8 years ago

I like to see the dpkg/apt system enhance to add audit feature - able log all the files added/modified/deleted as part the installation process, ideally in html format.

Any admin can view the contents to debug or spot any potential security issues.

TeMPOraL• 8 years ago

Forget admins, I'd love to have that as a user. I want to know where the application is and where it stores its data. And I mean all of the places.

tinus_hn3• 8 years ago

I don't get why we would want to allow packages to run any scripts before/after the installation.

That’s because you probably never built a package management system. If you limit the package management system to the actions you propose it’s only usable for iOS type apps and that could be useful but then you still need a solution for managing the rest of the system.

Stammon• 8 years ago

Please have a look at nix and solaris first. Both are making a compelling case against your answer

pilif2• 8 years ago

I'm having slight trouble understanding the threat vector this is supposed to be protecting against. If you don't trust a package's install script, why would you trust any of the binaries installed by that package?

If you're unsure about bugs in a package's install script, why aren't you equally unsure about bugs in the binaries installed by the package.

In-fact, install scripts are auditable; third party compiled binaries aren't (at least not easily).

I see other advantages in declarative approaches - for example more freedom for debian to change the underlying file system layout, or to give the user some information about what the package is going to change for easier troubleshooting, but I do not see any advantage security-wise.

saurik• 8 years ago

I mostly agree with you, but it is worth noting that most software is installwd by root but run by some "less privileged" user. That said, I still agree with you, as there is no data of value on any computer I own that is only accessible to root: all of the data that matters is in fact accessible to whatever the least privileged user that is using all of the software on that machine happens to be... on my laptop, that's me and on my database server that is my database. So really there is no difference between running software as root and running it as the "less privileged" user.

Like, the idea that I care that Chromium can run software as root is nonsensical: yes, root can modify all of the software not on my computer... to what end? The only thing of value on my computer is in my home directory, owned by me... hell, thanks to a bunch of people who (incorrectly) think they can make their computers safer by running fewer things as root, a ton of executable files are in my home directory thanks to userspace package managers provided by rust and node.js, so you can even modify other software without even having to be root anymore :/. There is simply no security advantage to any of this.

bluGill2• 8 years ago

There are a still a handful of multi-user linux systems out there. Chromium as non-root cannot read the other users files when you log into some evil site that knows of a backdoor. (Assuming no other root backdoor)

There is one other point: if my OS is sound and my user files are corrupted - well at least I can restore my files from backup without first trying to reinstall my machine. It saves a little effort.

08-15• 8 years ago

the "less privileged" user

You can have multiple user accounts, they don't need to be associated 1:1 with living people.

pilif2• 8 years ago

Also, if a package installed a suid binary, I would still have no recourse nor ability to audit and it would have full root rights.

And blanket warning about such packages would lead to a slew of false positives and warning fatigue (heck, even ping needs to be suid root)

peterwwillis4• 8 years ago

Docker is a nice idea. It's one tool, one system, for easily packaging software and running it, in an isolated environment. But Docker includes a lot of crap most people don't need. Do we need an isolated network for our apps? Do we need an isolated cgroup? Do we need to install a complete base image of an OS? Do we need root to run those apps? The answer, for most cases, is no.

Then there's things like Flatpak. They also want to make it easy to package and distribute software. And they see all the features of Docker and go, "Hey, a sandbox! That sounds cool! Let's make it mandatory!" In order to simply distribute software in a compatible way, they include a lot of restrictions they don't need to just distribute and run software.

All you need to distribute a software package is files, and a subsystem that maps files into the user's environment, and links together the files needed to run the software. We can accomplish this with a copy-on-write, overlay filesystem, and some software to download dependent files and lay them out in the right way. It should be incredibly simple, and it should work on any operating system that supports those filesystems. And those filesystems should be simple enough to implement on any operating system!

So what the hell is the deal here? Why has nobody come along and just provided the bare minimum needed to just distribute software (edit: in a way that also allows it to be run with all its dependencies in one overlay filesystem view)? Why is it always some ass-backwards incompatible crap that is "controversial" ? Why can't we just make something that works for any software?

rkeene24• 8 years ago

I did. http://appfs.rkeene.org/

You're welcome.

peterwwillis4• 8 years ago

Errr... that's not really what I'm looking for, my last paragraph was a bit inaccurate. But seems cool nonetheless.

Limiting the power of package installation in Debian

Related Stories