Re: Limiting the power of packages
On 2018-10-04 08:38:09, Paul Wise wrote:
> On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
>
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>
> anarcat wrote this related wiki page that covers this general topic:
>
> https://wiki.debian.org/UntrustedDebs
>
> The maintainer scripts are just the first problem that comes up when
> installing untrusted packages.
>
> There are myriad ways a package could install files that allow it to
> get root. setuid binaries, cron jobs, systemd units, apt keyring
> information, sudoers files and so on. The amount of stuff that can
> lead to root completely depends on the packages one already has
> installed. Then there are myriad other things that don't allow root
> that untrusted applications should not get hold of (like your private
> diary, some keys or passwords etc).
Yet I still think we should start fixing those problems. Yes, there are
a billion things that could go wrong in the current approach, but if we
had *some* safety net, controlled in the sources.list file, we could at
least restrict what third-party packages would do.
For example, there's no reason why a package like Chromium should be
able to run stuff as root. The vast majority of third-party repositories
out there mostly ship this one binary that does not require special
privileges other than installing stuff in /usr, without suid or any
special permissions.
> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.
>
> It might become possible to convert .debs to Flatpak using something
> like the ArchLinux approach for this and a future version of
> mmdebstrap that might allow installing sub-essential.
>
> https://wiki.archlinux.org/index.php/Flatpak#Creating_apps_with_pacman
Yes well, we *could* consider rewriting Debian to be based on
appimage/flatpak/snappy, but that would be a rather controversial
change. I think there are smaller, incremental steps we can take before
that to improve the situation without rewriting the whole world.
The wiki page I wrote was a short inventory of some of that stuff. There
are somewhat low-hanging fruits in there like declarative maintainer
scripts. I would also like to see end-to-end trust verification (like we
see on Android) for .debs, although I'm not exactly sure how that could
work in practice. At least shipping the signatures to allow some manual
verification would be an easy first step.
==
The devil, of course, is in the details, and someone needs to sit down
and make sense of all that stuff. It *is* true that the flatpak model
does try to address a lot of those issues and we might want to consider
that more closely.
Beyond this issue, what I'm mostly concerned about these days is
isolation between different apps. Our only solution on the desktop right
now is Qubes and it seems rather overengineered for my needs. Compared
with the security models of iOS or Android, we still have quite a lot of
work to do to make sure (say) my IRC client cannot steal my bank
credentials or (the horror!) vice-versa. ;)
A.
--
Man is, at one and the same time, a solitary being and a social being,
- Albert Einstein
Reply to: