The problem: when a .deb package is installed, upgraded, or removed, the maintainer scripts are run as root and can thus do anything.
Sometimes what they do is an unwelcome surprise to the user. For example, the Microsoft Skype .deb and the Google Chrome .deb add to the APT sources lists and APT accepted signing keys. Some users do not realise this, and are unpleasantly surprise. (Note that I'm not saying Microsoft or Google are doing something nefarious here: they're trying to make sure security updates for their packages will be deployed to user's system; this seems like a worthy goal. But it's a surprise to some users.) I don't think it's good enough to say the user shouldn't install third-party packages. It's not even good enough to say the user should use flatpaks or snaps instead: not everything can be packaged that way. Debian's own packages can have equally unwelcome surprises. Imagine a package that accidentally removes /var, but only under specific conditions. You'd hope that Debian's testing during a release cycle would catch that, but there's not guarantee it will. (That's a safety issue more than a security issue.) A suggestion: we restrict where packages can install files and what maintainer scripts can do. The default should be as safe as we can make it, and packages that need to do things not allowed by the default should declare they that they intend to do that. This could be done, for example, by having each package labelled with an installation profile, which declares what the package intends to do upon installation, upgrade, or removal. * default: install files in /usr only * kernel: install files in /boot, trigger initramfs * core: can install files anywhere, trigger anything * maintained-by-liw: full power to do anything This might be implemented in various ways. For example, dpkg could create a temporary directory, and bind mount the directories the profile indicates are needed, into a temporary shadow of the full system. Maintainer scripts would be run in the shadow environment. Thus, if they try to do something that isn't allowed by the packages profile, they can't. The profile should be in the Packages file, and each apt signing key should specify which repository (i.e., Packages file) it applies to. There may be per-key restrictions for what profiles are allowed. 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 to 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. -- I want to build worthwhile things that might last. --joeyh
signature.asc
Description: PGP signature