Re: Limiting the power of packages

[Guillem Jover <guillem@debian.org>]

Hi!

On Thu, 2018-10-04 at 08:38:09 +0800, 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.

Paul prompted a similar discussion the other day on #debian-apt after
posting a link to
<https://news.softpedia.com/news/skype-for-debian-could-allow-attackers-to-completely-takeover-machines-523013.shtml>
(which BTW seems like a complete bogus report to me, but oh well).

> 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).

IMO the whole premise is flawed. If you do not trust the .deb, then you
should not be even installing it using dpkg, less running it unconfined,
as its paradigm is based on fully trusting the .debs, on using shared
resources, and on system integration. Let me expand:

 * To "safely" install an untrusted .deb we'd need (at least) to disarm
   the following (current or future) features:
   - any dependency (Provides, Replaces, (Pre-)Depends, Conflicts, Breaks).
     + can be used to pull in new attack vectors, for their interfaces,
       vulnerabilities, or to interpose functionality for some of their
       optional features, f.ex.
   - any maintainer script.
   - any trigger activation.
   - any future declarative diversions, alternatives or user creation.
   - any char/block device.
   - any symlink.
   - any suid bit.
   - any future xattrs, acls.
   - installation on anything that is part of the standard paths,
     including **/usr**, /var, /etc, /bin, /sbin, /lib, etc.
     + installing under /usr, means you can interpose programs, or
       takeover names for optional functionality used by other
       privileged programs, or install things that might end up being
       used by a privileged user.
     + the only viable candidate might be /opt, and existing programs
       might be even trying to read from there, so it might not even
       be safe.

 * To "safely" (perhaps, but I'd rather not) run these untrusted
   programs, you'd better contain this as much as possible, different
   real users, namespaces, virtualization, whatever, but definitely
   not running these directly from the PATH unconfined.

   (But then, I'm personally not very impressed with the security state
   of Linux (or any Unix) due to layers upon layers of complexity and
   patchwork to plug the holes. IMO any systems that is not founded
   upon a capabillity-based security paradigm is doomed.
   <https://en.wikipedia.org/wiki/Capability-based_security>.)

 * Would need to define some way to denote these .debs as untrusted,
   but that should be done only by a trusted component, which (apt)?
   What happens if a user gets hold of such .deb and installs it
   manually with dpkg, not triggering the "untrusted mode"? Or we
   start signing the .deb container itself, and use debsig-verify to
   distinguish them.

 * Would need to define some kind of new metadata, that gets strongly
   validated, so that these stripped packages can get back some kind
   of integration in the system.

 * The only parts that have been "audited" and are considered attack
   vectors in dpkg are dpkg-deb and dpkg-source, as they can be used
   to analyze untrusted data. Everything else assumes fully trusted
   data.

So, while most of the above list could be implemented, what you get
left after stripping/disarming all the features, and adding back the
integration, etc., does not resemble a standard .deb, except for the
container format. :)

> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.

Exactly, if you do not consider the original premise flawed, you might
as well use one of the tools that has been designed precisely for that
purpose?

Thanks,
Guillem