Comment 85 for bug 1522675

@nc-duenkekl3
>Watch out, most of the time, it is a security hole, to run something as root.
>Privilege escalation is not something funny.
APT was executed as root for years, is not it?
Moreover root user is used as fallback or something (see https://git.launchpad.net/~usd-import-team/ubuntu/+source/apt/tree/apt-
pkg/acquire.cc?h=ubuntu/xenial-updates#n593 ). I'm not an author of this code.

Can you or maintainers suggest better solution?

Without sandboxing I get the following process tree (in htop):
USER COMMAND
root apt-get install ...
root dpkg ...
root sh ... postinst
root python3 .../package-data-downloader
root apt-helper download-file ...
root http

So 6 processes are run by root user.

With sandboxing I get the following process tree:
USER COMMAND
root apt-get install ...
root dpkg ...
root sh ... postinst
root python3 .../package-data-downloader
root apt-helper download-file ...
_apt (*) http

So only http (1/6) is called by _apt user. Is it really safer?
apt-get, dpkg, sh, python3, apt-helper may be vulnerable too (5/6 likelihood).
Http process download file, not execute it.
Downloadable file (/var/lib/update-notifier/package-data-downloads/partial/adobe-flashplugin_20170616.1.orig.tar.gz for example) has executable bit disabled for all users ("-rw-r--r-- 1 root root" or "-rw-r--r-- 1 _apt nogroup").
As far I can understand its contents will be checked by hash before installing.

Aptitude is affected too. And bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806595 was fixed in it.
Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813786 in apt was fixed too.

So I think that we need SRU for apt and aptitude.