9 ms·

Limiting the power of package installation in Debian

67 points by l2dy 8y ago

perlgeek 8y 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 8y 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.
  - bluGill 8y 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 8y 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 8y 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.
deleted 8y ago
[deleted]
frumiousirc 8y 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 8y 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 8y 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.
    - gronne 8y ago
      A bit ranty but i’l allow it because you are right. All praise his noodleness.
    - wlesieutre 8y ago
      For reference on Kite: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-...
    - coleifer 8y ago
      Thankfully they mostly stay in their own little excrement filled sandbox.
- scbrg 8y ago
heinrichhartman 8y 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.
- dTal 8y 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 8y 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.
    - Macha 8y ago
pilif 8y 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 8y 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.
  - bluGill 8y 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.
peterwwillis 8y 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?
- rkeene2 8y ago
  I did. http://appfs.rkeene.org/ http://appfs.rkeene.org/ You're welcome.
  - peterwwillis 8y ago
    Errr... that's not really what I'm looking for, my last paragraph was a bit inaccurate. But seems cool nonetheless.
    - rkeene2 8y ago
      It's literally what you described in the third paragraph: > 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! It's literally, and exactly that. I'm not sure how it can be not what you're looking for.

67 points by l2dy 8y 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 8y 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.
- bluGill 8y 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 8y 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 8y 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.

deleted 8y ago

[deleted]

frumiousirc 8y 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 8y 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 8y 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.
  - gronne 8y ago
    A bit ranty but i’l allow it because you are right. All praise his noodleness.
  - wlesieutre 8y ago
    For reference on Kite: https://forum.sublimetext.com/t/rfc-default-package-control-channel-and-package-telemetry/30157 https://forum.sublimetext.com/t/rfc-default-package-control-...
  - coleifer 8y ago
    Thankfully they mostly stay in their own little excrement filled sandbox.
scbrg 8y ago

heinrichhartman 8y 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.

dTal 8y 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 8y 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.
  - Macha 8y ago

pilif 8y 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 8y 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.
- bluGill 8y 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.

peterwwillis 8y 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?

rkeene2 8y ago
I did. http://appfs.rkeene.org/ http://appfs.rkeene.org/ You're welcome.
- peterwwillis 8y ago
  Errr... that's not really what I'm looking for, my last paragraph was a bit inaccurate. But seems cool nonetheless.
  - rkeene2 8y ago
    It's literally what you described in the third paragraph: > 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! It's literally, and exactly that. I'm not sure how it can be not what you're looking for.