What are the potential vulnerabilities of allowing non-root users to run apt-get?

Question

There are two ways I can think of doing this:

1. On a system with sudo, by modifying /etc/sudoers.

2. On a system without sudo (such as a Docker environment), by writing a program similar to the below and setting the setuid bit with chmod u+s. apt-get checks real uid, so a setuid call is necessary.

...
int main(int argc, char **argv) {
    char *envp[] = { ... };
    setuid(0);
    execve("/usr/bin/apt-get", argv, envp);
    return 1;
}

I have two questions:

1. What are the potential vulnerabilities of allowing non-root users to run apt-get?
2. My goal is to allow people to install/remove/update packages, given that apt-get lives in a custom non-system refroot and installs from a custom curated apt repository. Are there safer ways to allow non-root users to run apt-get on a system without sudo?

Answer 1

apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

From GTFOBins

This gives you a root shell on the system. No creating packages and adding fake repos; this will give the user who runs this command easy and simple access to root.

So, in answer to your question, you are effectively giving root to every user who has access to this binary. If you are willing to do this, then you might as well just give them sudo access or the root password.

Answer 2

You say you're using a "custom curated apt repository" but there's no way to enforce that. Any user that can invoke apt can specify their own source list, for example apt install root-backdoor -o Dir::Etc::Sourcelist=~/apt/my-own-sources.list. This can be done for all the other config settings as well, which means you can also have apt overwrite arbitrary files with content you choose (e.g. by setting the cache directory for retrieved packages).

Packages can (and often do) execute arbitrary commands during installation. Since the attacker can control the sourcelist, they can create malicious packages that either give unprivileged users a privileged backdoor, or simply execute (as root) any command the attacker desires as part of the "install" process.

apt is absolutely not a safe program to let people run (with root privileges) if you want to prevent them from running arbitrary code with root privileges.

EDIT: I want to call attention to this answer as a much cleaner way to get arbitrary execution (as root) out of apt.

Answer 3

Would preventing users from specifying their own sourcelists (e.g. by making a wrapper that specifically calls apt-get install -- <packages> with root privileges) be sufficient to prevent users from installing arbitrary packages (and thus prevent arbitrary code execution as root)?

Nope, apt-get can also pick up packages from paths. An attacker could create a malicious .deb package that patches /etc/<something> for root access upon installation via e.g. apt-get install -- /path/to/foo.deb.

You might be able to make it work securely if your custom wrapper script only accepts what's on a whitelist of package names, and if you can guarantee the packages are only picked up from your sources list - and can never be supplied via custom configs, environment variables, etc.

Answer 4

1. What are the potential vulnerabilities of allowing non-root users to run apt-get?

Full system compromise; Persistent privilege escalation from the user allowed to run apt-get to root.

2. My goal is to allow people to install/remove/update packages, given that apt-get lives in a custom non-system refroot and installs from a custom curated apt repository. Are there safer ways to allow non-root users to run apt-get on a system without sudo?

As explained here, you cannot guarantee this.

Answer 5

I actually strongly disagree with the answers so far, that's why I've added another perspective. My solution approach is roughly based upon one of @ Cyclic3's comments, but amended as required.

---

The actual attack vector:

When there already is a root shell, why deliver the payload by package manager? apt-get is not the main problem (as it is not essential to install software), but inappropriate software provisioning by unauthorized users is, which should better request the packages to be installed for them. Letting them surf the internet with a root account would be about the same idiocy, when looking at it from a security perspective.

On a side note, independent from apt-get, they always could wget some 0-day exploit, which performs privilege escalation. This would require white-listing destinations on the firewall to prevent, which does not amuse users in general, because this shuts down all of their random internet usage (which may also include job-related web research). This aspect is often being completely ignored.

---

One simple self-service solution:

Since nobody wants to play the server serf ...why not write a simple web UI, which let's them select the packages and then provision them to the machine they've requested from? Then just ssh into and run apt-get. This is a method of white-listing (I only know yum in detail, which does support black-listing but not white-listing). In general, this is a very simple way to almost guarantee zero risk, as the root shell & apt-get install are being kept outside of their reach. When triggering this as a batch job from the root crontab (assuming the root SSH keys match on all machines), one does not even have to switch the user account to do so. Just push a notify when done and they'll be amazed.

As I used to say, when working in user support: What they cannot click, they cannot mess up.