Limiting the power of package installation in Debian

Posted Nov 7, 2018 18:45 UTC (Wed) by Baughn (subscriber, #124425)
Parent article: Limiting the power of package installation in Debian

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.