How can two-man control be implemented with minimal overhead?
TL;DR This can be accomplished using a special
sudo command that requires a second person to approve each command, combined with a nice whitelist to make safer commands more convenient. It is important that each command is approved by the two-man rule or else the protection is easily defeated.
Two-man rule implementation options:
Unconstrained root access
root access temporarily
A small root script could require a second person (User A) to authorize before
sudo becomes available for the acting sysadmin (User B)
(auto-adds an entry to
/etc/sudoers with either a time-limit or scheduled removal via
sudo do stuff will start working at this point
Unfortunately, a back-door could easily be added by User B once User A has authorized the access. This could be as simple as re-adding
/etc/sudoers or starting a separate service.
It is not possible to robustly enforce security rules once someone has gained
root (as it is "unconstrained"), so you should covertly monitor the most likely bypass possibilities and alert another (more trusted) sysadmin if something begins looks odd after a two-man enabling of
- unexpected background process still running
- unexpected startup script
And don't tell them exactly what safeguards you are using. This will help against the obvious back-doors, especially if
user-b is not familiar with the protections in place, but will not thwart a
user-b who is determined to cause trouble.
Command-basis two-man rule
Create your own version of
sudo, which alerts the second person of any command suggested by the first person, with the ability to approve or deny.
I won't go into the implementation details here, but it would be fairly straight-forward to implement.
In this case, a back-door would have to be hidden within one of the provided files, for example a software update to be installed.
File editing with
Your custom version of
sudo should not allow launch of direct file editing commands. If someone types
oursudo vi, then
oursudo will have to launch a special script for file editing.
- Copy the file to a
/tmp location (randomly generated filename to prevent symlink attacks)
vim with reduced privileges to a non
root account (so
user-b cannot use the "Save As" function within
vim to bypass this wrapper)
- When saving is completed, present a
diff of the file changes to
- Once approved, copy the approved file from
/tmp to the target location.
Requiring physical access to gain
root access could help bring visibility to what
user-b is doing. Depending on the office environment, the team may have a clue to what
user-b is up to, and/or
user-b may be less comfortable causing trouble in that environment. It depends on how often such access is necessary though.
root = unconstrained
As you can gather from the ideas I've brought up, there does not seem to be a sure-fire to protect against back-door installations.
root access is designed not to allow this.
Whitelist commands approach (constrain the root access)
The best thing is to create a whitelist of available commands. (which
sudo has the ability to offer) This does create a significant overhead at first, but eventually may become more practical as you learn the command that are commonly used.
Deploying application updates
Your applications should not run on root access. Those that do must go through a separated Code Review system and then updates from the approve VCS commit can be included.
Patching [packaged] software
This is cannot be constrained, so I would suggest using command-basis two-man rule outlined above.
Safe tools can be permitted via
sudo, and then use command-basis two-man rule to roll the fix.