Web lists-archives.com

Re: Limiting the power of packages




in /usr only ?...

I thought therefore in later years Linux had created /opt ?



Lars Wirzenius <liw@xxxxxx> 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