7

I have an SSH standard user account on my personal server, and it has sudo access (via its password).

I ssh in using a public key, so I don't have to type in the account password to log in. Is it safe for me to allow this user passwordless sudo access to run only the apt-get update and apt-get upgrade (or apt-get dist-upgrade) commands? I'm asking from a security standpoint, not from a 'broken/buggy update' standpoint. I am the only one logging in, and if I break something with an update, I can always sudo (with a password) to fix things.

The main point is to be able to run timely updates on my server without needlessly typing in a password. But, if someone did get access to this account, I don't want them to be able to install anything, and I don't know if there are other concerns I should have with these two commands.

Here is the exact line in my sudoers file:

stephen ALL=(root) NOPASSWD: /usr/bin/apt-get update, /usr/bin/apt-get upgrade, /usr/bin/apt-get dist-upgrade

  • 3
    The only concern I see is that sometimes upgrades allow for running an interactive sub-shell whenever configuration file changes collide. – user86969 May 24 '15 at 18:32
  • 1
    Think of it like this: can you fool apt-get update to pull updates from a fake repository? Say, with a little DNS cache poisoning? – lcd047 May 24 '15 at 18:57
  • 1
    @lcd047 Don't packages get signed by canonical, or whichever repository the upgrade is coming from? Even if DNS got poisoned, I thought tampered packages would not work since it has a different signer. But it's a good point if they aren't signed. – Stephen Schrauger May 24 '15 at 19:17
  • @Nasha That is a very good point! I hand't thought of collision resolving. – Stephen Schrauger May 24 '15 at 19:17
  • 1
    Even if the packages are signed, you don't need to actually install them to make the life interesting for the sysadmin. Consider f.i. fooling the system into pulling a 10TB file from your fake repository (and again, you don't need an actual 10TB file to serve 10TB of selected excerpts from /dev/urandom over HTTP). Signatures can't prevent that, since they can only be verified after a file has been downloaded. – lcd047 May 24 '15 at 19:36
8

Allowing a less trusted user to run apt-get update is ok. They worst they can do is consume a lot of bandwidth and fill up some disk space, and they have plenty of other means to do this unless you've taken stringent measures to prevent this.

Allowing a user to run apt-get upgrade is likely to give them root access. Some packages query the user and might allow a shell escape; for example the user who has access to the terminal that apt-get upgrade (or any dpkg -i call) is running on might get prompted for what to do if a configuration file has been updated, and one of the options there is to run a shell to examine the situation.

You need to restrict the command some more:

#!/bin/sh
set -ex
exec </dev/null >"/var/log/automatic-apt-upgrade-$(date +%Y%m%d-%H%M%S)-$SUDO_USER.log" 2>&1
apt-get --assume-no upgrade

This shouldn't give the user a way to become root, since they can't interact with the package manager. As upgrades can sometimes break a system, and a user with only these permissions wouldn't be able to repair anything, this should only be done with a stable release, with only security updates pending. If it's a kernel update, let a user with full root access decide when to trigger a reboot.

By the way, the user wouldn't be able to inject package content — to do that, they'd need to be in control of the server distributing the package, and in addition to the server signing the package if the package is signed (which is the case for all official sources). It's irrelevant for this attack vector who's in command of the machine at the time of the upgrade.

All this being said… use unattended-upgrades, if that's what you want.

  • Can I not just use NOEXEC? The ubuntu docs for sudoers states ...you can also use NOEXEC to prevent any programs launching shells themselves (as once a program is running with sudo it has full root privileges so could launch a root shell to circumvent any restrictions in the sudoers file. - help.ubuntu.com/community/Sudoers – Programster Jul 13 '15 at 6:43
  • @Programster If you use NOEXEC, the installation of most packages will fail because their postinst and other scripts will not run. – Gilles Jul 13 '15 at 9:32
  • good to know, if I use your script, can an admin run an upgrade later and make the upgrade choices or will those packages be considered "installed" and chosen to do nothing? – Programster Jul 13 '15 at 11:19
  • @Programster The installation would fail, the packages would remained in a half-installed state (with the files in place, but not usable). – Gilles Jul 13 '15 at 11:28
  • I guess the "rule of thumb" is don't allow non-sudo users access to the upgrade functionality then, only sudo apt-get update, and maybe look more into unattended-upgrades. – Programster Jul 13 '15 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.