Is there something like one-time sudo

Requiring dual approval for certain actions is part of some security policies; for example:

• In banking, very large transactions typically require validation by two managers.
• Launching heavy weapons such as nukes requires validations by two or more high-ranking officers or decision-makers.
• Approving or rejecting a suggested edit on Stack Overflow requires two users with sufficient reputation to agree.

You'll note that this is not about authentication (e.g. typing a password to show that you're who you pretend to be), but about authorization, i.e. deciding whether a certain action is permitted.

For background reading, I recommend Security Engineering by Ross Anderson. Buy the latest edition if you can, but otherwise the first edition is available online. The most relevant chapter is “Access Control”; there are examples in the chapters on banking and nuclear command.

Unix offers a simple security model, with only two levels: user and superuser. This is both a strength (simple means less room for errors in the design and implementation of the system itself and of security policies) and a weakness (complex security policies cannot be expressed natively). If you're worried about a rogue user gaining root, don't give him root permissions. There are very few checks on what root does; the only constraint would be that the action of gaining root can be logged remotely, as can certain external actions (network traffic). A rogue user could pretend to want to gain root to do a certain thing and actually do another while hiding his actions from the other user. So you would not gain much security by requiring root access to be vetted by another user. Conversely, you would lose security by reducing the availability of root access (I gather you want to give less trusted users root access to serve as back-ups if something goes wrong; dual approval would increase the burden a lot).

Dual approval is useful for specific actions: Alice says “please authorize me do do X”, Bob says “I authorize Alice to do X”, and the system performs X (X can be e.g. transferring $1,000,000,000 from one bank account to another, or nuking Moscow, or rejecting an edit). If Alice says “please authorize me to do anything I want” and Bob agrees, all Bob is doing is echoing what you (the policy maker) already said, namely that Alice can be authorized to do anything. You might as well make Alice a sudoer.

I don't know of any existing system on unix to have multiple users approve specific commands in a sudo-like framework.

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.