UNIX ha un doppio meccanismo di approvazione?

Un metodo che ho visto usato: dividere la password. Questo era per l'accesso SSH a un server sensibile: un certo numero di chiavi SSH sono state create e contrassegnate come "autorizzate" sul server. Ogni chiave privata era protetta con una passphrase lunga e ogni utente conosceva solo metà della passphrase.

È rozzo ma efficace purché non ci siano troppi amministratori. Per gli amministratori N "doppio controllo", è necessario N (N + 1) / 2 tali chiavi (ad esempio 55 chiavi se si hanno 10 amministratori), che di solito è accettabile. Ogni amministratore deve solo ricordare una "mezza passphrase". Lo stesso concetto può essere esteso a sudo impostando account specifici N (N + 1) / 2 (ad es. Admin Bob e admin Dave type sudo -u bob_dave thecommand e account bob_dave fa parte della pertinente gruppo, o forse viene dato UID 0 in modo da essere un alias su root ).

Il doppio controllo è preventivo nel seguente senso: l'attaccante deve corrompere due amministratori invece di uno (il che significa che gli costerà il doppio in pinte di Guinness).

Non sono a conoscenza di alcun sistema integrato progettato per il concetto di due persone a livello di sistema operativo. Mentre una nuova versione di sudo / PAM potrebbe essere scritta per ottenere ciò, mi sembra che sia meglio applicata a livello di applicazione rispetto al livello del sistema operativo, personalizzata nell'applicazione per i tuoi scopi specifici. I dati possono essere crittografati con più chiavi (appartenenti a diversi utenti) per assicurare che root utenti non possano facilmente ignorare i controlli.

Che cosa immaginate - due persone sedute allo stesso banco dove l'utente A autentica e poi l'utente B autentica e quindi esegue il comando sudo? O l'utente A digita sudo emacs /etc/ssh/sshd_config , un messaggio viene inviato all'utente B che deve utilizzare i suoi dettagli di autenticazione su OK che l'utente A può modificare il file prima che possa modificare un file?

E di nuovo con il flusso di lavoro standard, hai il permesso di aprire l'editor di testo come superutente prima di aprire il file o di creare modifiche. Quindi potresti avere il permesso dell'utente B di fare sudo emacs /etc/ssh/sshd_config ma una volta che emacs (come superuser) è aperto potresti iniziare a modificare qualsiasi numero di altri file (ad esempio apri e modifica /etc/shadow , sostituendo un hash di un altro amministratore che è andato avanti vacanza) o aprire una shell superuser da emacs (senza alcuna riproposizione di credenziali o registrazione aggiuntiva dell'uso di sudo nella /var/log/auth.log sotto l'installazione standard).

In qualche modo correlato, è possibile impostare l'autenticazione a due fattori per ssh con yubikey o google . Quindi è possibile impostare uno scenario in cui è richiesta l'autenticazione a due fattori per l'accesso, richiedere che entrambe le persone siano presenti mentre gli utenti hanno effettuato l'accesso (ad esempio, entrambi possono essere attivati se qualcosa di malevolo è annotato nei registri) con ciascun membro che ne ha uno solo dei fattori per accedere.

Non che io sappia su base comando per comando, sebbene tu possa simularlo usando sudo con autenticazione a due fattori (es. yubikey), e dare un fattore a ciascun keyholder.

Ma avevo un cliente che voleva qualcosa di simile in senso assoluto, quindi abbiamo installato il tripwire nelle caselle pertinenti. Gli amministratori di sistema avevano i poteri sudo per eseguirlo, ma non le chiavi; la gestione aveva le chiavi, ma nessun privilegio. Certo, noi amministratori possiamo confondere le cose con i contenuti dei nostri cuori, ma i riassunti tripwire notturni di tali modifiche sono stati inviati via email alla direzione e non li avrebbero firmati (inserendo la passphrase con un comando tripwire --update ... , e scrivendo un voce firmata in un registro di modifica) fino a quando non avremo spiegato quali sono stati i cambiamenti e perché.

Non era infallibile, ma era difficile per un singolo sysadmin (o un singolo membro del management team) bypassare in modo non rilevabile.

Anche se potrebbe esserci un problema se si dispone di restrizioni sull'aggiunta di software, sarebbe relativamente semplice scrivere una versione di "su" ( ecco le ossa di un'implementazione convenzionale).

Sarebbe possibile implementare 2 autenticazione utente come modulo pam, ma non penso che potresti impilarlo con altri moduli che forniscono l'autenticazione, quindi utilizzare un singolo binario setuid che chiama pam per ciascun utente in modo indipendente.

(perché è che ogni client pam usa 'goto' dappertutto!)