¿Tiene UNIX un mecanismo de aprobación dual?

Un método que he visto usado: dividir la contraseña. Esto fue para el acceso SSH a un servidor sensible: se crearon varias claves SSH y se marcaron como "autorizadas" en el servidor. Cada clave privada estaba protegida con una frase de contraseña larga, y cada usuario conocía solo la mitad de la frase de contraseña.

Eso es burdo pero efectivo siempre y cuando no haya demasiados administradores. Para los administradores de "control dual" de N , necesita N (N + 1) / 2 tales claves (por ejemplo, 55 claves si tiene 10 administradores), lo que generalmente es aceptable. Cada administrador solo necesita recordar una "frase de contraseña". El mismo concepto se puede ampliar a sudo configurando N (N + 1) / 2 cuentas específicas (por ejemplo, el administrador Bob y el administrador Dave escriben sudo -u bob_dave thecommand y la cuenta bob_dave es parte de grupo, o tal vez se le da UID 0 para ser un alias en root ).

El control dual es preventivo en el siguiente sentido: el atacante debe sobornar a dos administradores en lugar de uno (lo que significa que le costará el doble en pintas de Guinness).

No tengo conocimiento de ningún sistema incorporado diseñado para el concepto de dos personas a nivel de sistema operativo. Si bien se puede escribir una nueva versión de sudo / PAM para lograr esto, me parece que se aplica mejor en el nivel de la aplicación que en el nivel del sistema operativo, personalizado en la aplicación para sus propósitos específicos. Los datos se pueden cifrar con varias claves (que pertenecen a diferentes usuarios) para garantizar que los usuarios de root no puedan omitir fácilmente los controles.

¿Qué imaginas: dos personas sentadas en el mismo escritorio donde el usuario A se autentica y luego el usuario B se autentica y luego se ejecuta el comando sudo? ¿O el usuario A escribe sudo emacs /etc/ssh/sshd_config , se envía un mensaje al usuario B que tiene que usar sus datos de autenticación para que el usuario A pueda editar el archivo antes de editarlo?

Y nuevamente con el flujo de trabajo estándar, obtienes permiso para abrir tu editor de texto como superusuario antes de abrir el archivo o crear cambios. Así que posiblemente podrías obtener el permiso del usuario B para hacer sudo emacs /etc/ssh/sshd_config pero una vez que emacs (como superusuario) esté abierto, puedes comenzar a editar cualquier número de otros archivos (abre y edita /etc/shadow , reemplazando un hash de otro administrador que continuó vacaciones) o incluso abrir un shell de superusuario desde emacs (sin ningún reprompido de credenciales o registro adicional de uso de sudo en el /var/log/auth.log bajo la configuración estándar).

Algo relacionado, es posible configurar la autenticación de dos factores para ssh con un yubikey o google . Por lo tanto, podría configurar un escenario en el que requiera la autenticación de dos factores para iniciar sesión, requerir que ambas personas estén presentes mientras los usuarios inician sesión (por ejemplo, ambos pueden activarse si se nota algo malicioso en los registros) con cada miembro teniendo solo uno de los factores para iniciar sesión.

No que yo sepa sobre una base de comando por comando, aunque podría simularlo utilizando sudo con autenticación de dos factores (por ejemplo, yubikey), y dar un factor a cada titular de clave.

Pero tenía un cliente que quería algo como esto en un sentido general, por lo que instalamos tripwire en las casillas correspondientes. Los administradores de sistemas tenían los poderes de sudo para ejecutarlo, pero no las claves; La gerencia tenía las llaves, pero no privilegios. Claro, los administradores podríamos meternos con cosas del contenido de nuestros corazones, pero los resúmenes nocturnos de esos cambios fueron enviados por correo electrónico a la administración, y no los aprobaron (ingresando la frase de contraseña con el comando tripwire --update ... y escribiendo una ingreso firmado en un libro de registro de cambios) hasta que hayamos explicado cuáles fueron los cambios y por qué.

No fue infalible, pero fue difícil para un solo administrador del sistema (o un solo miembro del equipo de administración) omitir de manera indetectable.

Aunque puede ser un problema si tiene restricciones para agregar software, sería relativamente sencillo escribir una versión de 'su' ( aquí están los huesos de una implementación convencional).

Sería posible implementar la autenticación de 2 usuarios como un módulo pam, pero no creo que puedas apilarlo con otros módulos que proporcionan autenticación, por lo tanto, usar un único binario de setuid que llame a pam para cada usuario de forma independiente.

(¿por qué es que cada cliente pam usa 'goto' por todas partes?)