sudo -u utente cmd vs sudoedit

Question

sudo -u utente cmd vs sudoedit

#1 da (1 voti)

2

Ho letto su internet che devi usare sudoedit invece di sudo vim. Capisco perché questo è e dovrebbe essere usato in modo che tu non possa semplicemente modificare i file dell'utente root.

Tuttavia mi piacerebbe gestire un utente di nologin (account di servizio che esegue una singola applicazione) chiamiamola "nologinuser" con il mio account non-root . Per questo avrei bisogno dei diritti corretti nel file sudoers.

Sono stato in discussione con 2 gestori di sistemi Linux ed entrambi non sono d'accordo.

l'amministratore di Linux A dice: dovresti creare una regola sudoedit per ogni file di configurazione e una regola sudo per ogni comando.

L'amministratore B di Linux dice: basta creare una regola sudo che ti permetta di leggere / scrivere / eseguire tutto come quell'utente con "sudo -u nologinuser *"

Personalmente sono d'accordo con l'amministratore B perché con "sudo -u nologinuser" puoi eseguire ogni comando solo come tale utente, e tramite questo comando hai ereditato anche i suoi diritti perché lo esegui come tale utente. Questo inoltre non causerebbe un problema di sicurezza nella capacità di modificare i file dell'utente root perché nulla è fatto come root ed è molto flessibile.

Chi ha ragione o c'è una terza opzione migliore? Chi può dirmi la migliore pratica in questo. Qual è il modo migliore per gestire un utente dell'applicazione nologin come non root?

Grazie.

linux root sudo

posta C-3Pi-O 17.10.2017 - 15:21

fonte

1 risposta

Leggi altre domande sui tag linux root sudo

Progettazione di CP e CPS per più CA gerarchiche Come interrompere l'accesso rapido dal salvataggio di cartelle crittografate?

score 1 · Answer 1

Dipende da quali sono i tuoi bisogni esatti.

Soluzione A : questa è quella preferita quando si eseguono i comandi come utente privilegiato (forse root, forse un altro account che ha più privilegi di un utente standard). Ciò consente di definire una politica che descrive le azioni esatte da consentire, in modo che questo utente non possa subire abusi da parte di utenti non privilegiati (sia malintenzionati che errati).
Soluzione B : in termini di privilegi è strettamente equivalente a fornire una shell interattiva come nologinuser (con una migliore gestione di audit e password rispetto a tu la password dell'account di destinazione).

Come per il tuo messaggio, ho l'impressione che non ci siano problemi reali nel consegnarti una shell come nologinuser , tuttavia la flessibilità potrebbe essere un problema (non vuoi avere per chiamare l'amministratore ogni volta che vuoi un nuovo comando, opzione o file aggiunto al file sudoers ) e la tua preoccupazione principale è che nessuna azione debba essere eseguita come root.

Se la mia comprensione del tuo messaggio è corretta, sceglierei la soluzione B .

Hai ragione nel ritenere che consentire a user_1 di eseguire comandi come user_2 utilizzando sudo non fornisce alcun privilegio root a < em> user_1 , direttamente o indirettamente.

Spesso le persone hanno l'impressione sbagliata che sudo fornisce superpoteri. Mentre il suo uso più comune è in effetti eseguire comandi come root , può anche essere usato con l'effetto contrario per diminuire i privilegi di un comando.

Personalmente uso spesso sudo per eseguire un comando come utente con privilegi più bassi (un demone, un'utilità di trasferimento file, ecc.). In questi casi non ha senso limitare i comandi eseguibili, basta definire quali utenti possono eseguire comandi come questo nologinuser e in quali condizioni (password richiesta o meno, variabili d'ambiente da mantenere, ecc.) E tu andrà bene.