status
failed

# Or: Why you don’t let untrusted users “sudo apt-get install”

I was going through my reading list, and I found this great article, entitled “Nobody expects command execution”.

tl;dr: Lots of commands in linux have an option to let you run arbitrary commands. If you let users run those commands with sudo or setuid root they can get a root shell. Check it out, it’s got juicy examples.

This blog post is just one example of command execution using sudo apt-get.

## But why would you let your users do that!?

Letting non-admin “semi-trusted” users install their own software is a pretty common desire. If you don’t let them, you tend to end up with 50GB+ home directories containing the entire Gentoo package set just so they can use zsh.

Really, sudo seems the obvious way to let users install software. There are plenty of examples of web pages either suggesting to use sudo, or that it’s merely “less secure” than the “correct” solution (which seems to be Polkit?).

“less secure” is a bit misleading: it’s easy to get a root shell once you can sudo apt-get.

## Here’s how

echo 'Dpkg::Pre-Invoke {"bash";};' > dpkg-opts
sudo apt-get install cowsay -c=dpkg-opts

What this does is to ask apt-get install to supply extra flags to dpkg. dpkg lets you insert arbitrary scripts as hooks, so all you need to do is set “bash” as your hook, and you get dropped into a root shell during the installation process.

This requires that cowsay is not installed (if it is, the hook won’t run), but you can always pick a different package or uninstall it.

While this is pretty widely acknowledge as a risky thing to do, I couldn’t find any actual examples of why. Hopefully this will be helpful to people considering giving out sudo apt-get priviliges to users!