Sudo and logging is used to keep administrators accountable. But is there a command/configuration that lets you enforce a dual approval type control such as the the "Two Person Concept"? (eg. Two authorised individuals are required to launch an nuclear weapon.)
Sudo can be set up to log actions performed by administrators but this is only a detective control. How could you implement a preventative control that enforces the appropriateness of the command being executed?
One method which I have seen used: split the password. This was for SSH access to a sensitive server: a number of SSH keys were created, and marked as "authorized" on the server. Each private key was protected with a long passphrase, and every user knew only one half of the passphrase.
That's crude but effective as long as there are not too many administrators. For N "dual control" administrators, you need N(N+1)/2 such keys (e.g. 55 keys if you have 10 administrators), which is usually acceptable. Each administrator needs only remember one "half-passphrase". The same concept can be extended to sudo by setting N(N+1)/2 specific accounts (e.g. admin Bob and admin Dave type sudo -u bob_dave thecommand and account bob_dave is part of the relevant group, or maybe is given UID 0 so as to be an alias on root).
Dual control is preventative in the following sense: the attacker must bribe two admins instead of one (which means that it will cost him twice as much in pints of Guinness).
I'm not aware of any built in system designed for the two-person concept at the operating system level. While a new version of sudo/PAM could be written to accomplish this, it seems to me to better enforced at the application level than the operating system level, customized in the application for your specific purposes. Data can be encrypted by multiple keys (belonging to different users) to assure that root users cannot easily bypass controls.
What do you envision -- two people sitting at the same desk where user A authenticates and then user B authenticates and then the sudo command executes? Or user A types in sudo emacs /etc/ssh/sshd_config, a message gets sent to user B who has to user their authentication details to OK that user A can edit the file before they can edit a file?
And again with the standard workflow, you get permission to open your text editor as superuser before opening the file or creating changes. So you could conceivably get permission from user B to do sudo emacs /etc/ssh/sshd_config but once emacs (as superuser) is open you could start editting any number of other files (say open and edit /etc/shadow, replacing a hash of another admin who went on vacation) or even open up a superuser shell from emacs (without any reprompting of credentials or additional logging of use of sudo in the /var/log/auth.log under the standard setup).
Somewhat related, it is possible to setup two factor authentication for ssh with a yubikey or google. So you could set up a scenario where you require two factor auth for logging in, require both people to be present while the users are logged in (e.g., both can be fired if anything malicious noted in the logs) with each member having only one of the factors to login.
Not that I know of on a command-by-command basis, though you could simulate it by using sudo with two-factor authentication (eg, yubikey), and give one factor to each keyholder.
But I did have a client that wanted something like this in an overarching sense, so we installed tripwire on the relevant boxes. The sysadmins had the sudo powers to run it, but not the keys; management had the keys, but no privileges. Sure, we admins could mess with things to our hearts' content, but nightly tripwire summaries of those changes were emailed to management, and they wouldn't sign them off (by entering the passphrase at a tripwire --update ... command, and by writing a signed entry in a change logbook) until we'd explained what the changes were, and why.
It wasn't foolproof, but it was hard for a single sysadmin (or single member of the management team) to bypass undetectably.
While it may be an issue if you have restrictions on adding software, it'd be relatively simple to write a version of 'su' (here's the bones of a conventional implementation).
It would be possible to implement 2 user authentication as a pam module, but I don't think you could stack it with other modules providing authentication - hence using a single setuid binary which calls pam for each user independently.
(why is it that every pam client uses 'goto' all over the place!)
