Impedire a sudo di richiedere la password quando si esegue un comando non consentito


15

Ho concesso l'autorizzazione di gruppo per eseguire determinati comandi senza password tramite sudo. Quando uno degli utenti inserisce un errore di battitura o esegue un comando errato, il sistema richiede la password e viene visualizzato un errore. Questo è fonte di confusione per l'utente, quindi vorrei solo visualizzare un errore invece di richiedere loro una password. È possibile?

Ecco un esempio del mio file sudoers:

%mygroup ALL=(ALL) NOPASSWD:/usr/local/bin/myscript.sh *

Esempio quando eseguono lo script sbagliato:

# sudo /usr/local/bin/otherscript.sh
[sudo] password for user:
Sorry, user user is not allowed to execute '/usr/local/bin/otherscript.sh' as root on <hostname>.

Uscita desiderata:

Sorry, user user is not allowed to execute '/usr/local/bin/otherscript.sh' as root on <hostname>. Please check the command and try again.

Notare la mancanza della richiesta della password.

Il mio google-fu non ha funzionato e restituisce risultati solo quando non viene richiesta una password quando l'utente è autorizzato a eseguire il comando.


8
Se ciò fosse possibile, potrebbe aprire una (piccola) falla di sicurezza. Se ti sei lasciato loggato e "prendo in prestito" la tua tastiera, non riesco a vedere quali comandi sudoti consentiranno di eseguire senza inserire la password. Con la funzione desiderata, potrei ottenere tali informazioni per comandi specifici.
Keith Thompson,

4
Questo è un grosso problema di sicurezza. Non dovresti usare sudo con script come comando. Le persone possono semplicemente modificare lo script ed eseguire tutto ciò che vogliono completamente mascherandolo da un controllo. Invece aggiungi la chiamata a sudo all'interno dello script.
Coteyr,

1
@coteyr che esegue file binari sudoè altrettanto grave se gli utenti hanno accesso in scrittura a questi file.
Dmitry Grigoryev il

1
@CarlWitthoft ecco perché usi percorsi assoluti per specificare i programmi consentiti nei sudoer.
Dmitry Grigoryev il

1
@DmitryGrigoryev, sì, ma se hai intenzione di usare sed o alcuni di questi per un solo file, non c'è alcun vantaggio su sudo. Consentire a un utente di modificare un file è il motivo per cui i file dispongono delle autorizzazioni. Non è necessario reinventare la ruota. Se vuoi che un utente sia in grado di modificare un file, allora lascialo. Non è necessario o beneficiare di saltare attraverso i cerchi con sudo per consentire a un utente di modificare un file, senza password. Puoi sempre permetterglielo. Strumento giusto per il lavoro giusto.
Coteyr,

Risposte:


25

Da una rapida lettura di sudo(8)

   -n          The -n (non-interactive) option prevents sudo from
               prompting the user for a password.  If a password is
               required for the command to run, sudo will display an error
               message and exit.

E per i dubbiosi:

# grep jdoe /etc/sudoers
jdoe    ALL=(ALL) NOPASSWD: /bin/echo
#

Testato così:

% sudo echo allowed
allowed
% sudo -n ed             
sudo: a password is required
% sudo ed               

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password:

Quindi un aliasfor sudoper queste persone probabilmente farebbe il trucco, per impedire la richiesta della password. Ora perché questo richiede una compilazione personalizzatasudo , non lo so, ho appena letto il manuale.


Infatti. Metterei qualcosa di simile alias sudo="$(which sudo) -n"in / etc / bashrc, quindi utilizzerei sudo(comportamento adattato) o command sudo(comportamento predefinito) come desiderato.
un CVn il

7

Una cosa che ha funzionato per me (Sudo versione 1.8.17p1), ma soddisfa solo una parte del tuo problema, è impostare il numero di tentativi di password su 0.

Defaults:%mygroup passwd_tries = 0

Questo fa uscire sudo con il codice 1 quando viene provato qualsiasi comando che richiede una password. Tuttavia, non produce alcun tipo di messaggio di errore.


Anche questa è una risposta valida, ma la mancanza di un messaggio di errore potrebbe creare confusione. Anche l'errore corretto ma inaspettato della risposta sopra è confuso. Immagino sia una scossa. Grazie per aver fornito una risposta alternativa, le opzioni sono sempre apprezzate!
user184982

2

Non puoi.

Non c'è modo di dire chi sei fino a quando non ti sei autenticato e, per impostazione predefinita, non puoi autenticarti senza una password.

È possibile modificare l'autenticazione per utilizzare chiavi USB, scanner di impronte digitali, autenticazione vocale, riconoscimento facciale o un sacco di altre cose, ma il punto è lo stesso.

Non è possibile eseguire l'autenticazione, senza autenticazione E prima di autenticare sudo non è necessario dirti cosa è possibile eseguire o meno.


2
Digitare la password quando si esegue sudo non è identificativo ("dire chi sei"). Il Sudo sa chi sei. Digitare la password è la conferma di presenza.
Gilles 'SO- smetti di essere malvagio' il

Considero la conferma di presenza come "autenticazione". Come in Autenticazione, quindi Autorizzazione.
Coteyr,

2
La risposta dice "autenticazione" non "identificazione". Mentre sudo sa chi pretende di essere, in base all'utente che ha effettuato l'accesso su quel terminale, non sa chi sei sei finché non si è autenticato l'identità.
Dave Sherohman,

2

@StrongBad ha fatto un commento che merita di essere una risposta:

Penso che la soluzione migliore sarebbe quella di scrivere uno script wrapper che chiama sempre sudocon i parametri corretti. (Compreso-n )

Lo script wrapper può eseguire l'analisi degli argomenti ecc. In modo che lo script sudo chiamato diventi il ​​più piccolo possibile e quindi meno probabile che abbia dei bug.


1

Non è possibile. L'unico modo è cambiare il codice sorgente e compilare il proprio fork disudo


Hai ragione, ma non credo che avrò il permesso di caricare una versione personalizzata di sudo su tutti i nostri server di produzione. hah
user184982
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.