in /usr only ?... I thought therefore in later years Linux had created /opt ?
Lars Wirzenius <l...@liw.fi> schrieb am Mi., 3. Okt. 2018, 19:19: > 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 >
