Le 04/10/2018 à 13:20, Paride Legovini a écrit :
> Lars Wirzenius wrote on 03/10/2018:
>> 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.
>
>> A suggestion: we restrict where packages can install files and what
>> maintainer scripts can do.
>
>> 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
>
> This would be a nice safety feature for users and for us maintainers: I
> know I won't screw up anybody's system with a font package as I
> restricted it to /usr/share and /etc/fonts.
>
> But I don't think it would solve the problem you pose. Who is going to
> set the profile? If if is the 3rd party packager, they will just use
> 'core' and install their APT source (or whatever they want). If it can
> be specified or overridden by the user at install time, then trying to
> install Skype with --profile=default will make the installation fail,
> and the user will just resort to --profile=core.
>
> Paride
Hi all,
other ideas:
- use a sort of restricted shell (or a meta language) for {pre,post}int
scripts and debian/rules: only access to debconf db and its own files
=> So no way to execute a custom script during install.
- remove suid bits unless package is signed by Debian: it means that
there could be 2 different key stores: apt one and dpkg one
My 2 cents...
Xavier
