La maggior parte delle volte, quando si installa un programma dal sorgente, si consiglia di creare un nuovo utente e un nuovo gruppo e fornire /usr/local/<myapp> l'utente creato di recente e la proprietà del gruppo.
-
Perché tale pratica è considerata una buona pratica?
-
Cosa migliora?
Esempio:utente mysql/gruppo mysql per il server di database MySQL.
Risposta accettata:
La pratica non consiste nel creare un utente e un gruppo per applicazione, ma per servizio. Cioè, i programmi eseguiti da un utente locale non devono essere installati come utente diverso da root. Si tratta di demoni, programmi in esecuzione in background e che eseguono richieste provenienti dalla rete o da altri mezzi di comunicazione, che dovrebbero essere eseguiti come utente dedicato.
Il demone viene eseguito come utente dedicato in modo che se si comporta male (a causa di un bug, probabilmente innescato da un attaccante) il danno che può fare è limitato:solo i file di dati del demone sono interessati (a meno che l'attaccante non sia riuscito a trovare una root hole locale , cosa che può succedere). Ad esempio, il demone del database mysqld viene eseguito come utente dedicato e gruppo mysql:mysql e i file di dati del database (/var/lib/mysql/* ) appartengono a mysql:mysql .
Si noti che l'eseguibile del demone e altri dati statici e file di configurazione che vengono utilizzati ma non devono essere modificati dal demone non devono appartenere all'utente dedicato; dovrebbero essere di proprietà di root:root , come la maggior parte dei file di programma e configurazione. Il mysqld il processo non ha attività di sovrascrittura di /usr/sbin/mysqld o /etc/mysql/my.cnf , quindi questi file non devono appartenere a mysql utente o essere scrivibile da mysql utente o mysql gruppo. Se alcuni file devono essere leggibili solo dal demone e dall'amministratore, dovrebbero essere di proprietà dell'utente root e del gruppo dedicato e avere la modalità 0640 (rw-r----- ).
Una categoria speciale di eseguibili che non possono essere di proprietà di root:root sono programmi che vengono invocati da un utente ma devono essere eseguiti con privilegi extra. Questi eseguibili devono essere setuid root se devono essere eseguiti (almeno in parte) come root; quindi l'eseguibile deve avere la modalità 4755 (rwsr-xr-x ). Se il programma necessita di privilegi extra ma non come root, allora il programma dovrebbe essere impostato su setgid, in modo che i privilegi extra arrivino attraverso un gruppo e non attraverso un utente. L'eseguibile ha quindi la modalità 2755 (rwxr-sr-x ). I motivi sono due:
- L'eseguibile non dovrebbe essere autorizzato a modificarsi, in modo che se un utente riesce a sfruttare una vulnerabilità, potrebbe essere in grado di modificare i file di dati utilizzati dal programma ma non iniettare un cavallo di Troia nell'eseguibile per attaccare altri utenti eseguire il programma.
- Il file di dati dell'eseguibile appartiene al gruppo. Un programma setuid dovrebbe passare dall'utente reale (l'utente che ha invocato il programma) per interagire con l'utente e con l'utente effettivo (l'utente con cui è in esecuzione il programma) per accedere ai suoi file di dati privati (il motivo avere privilegi extra). Un programma setgid può inoltre separare i dati per utente che sono accessibili solo al gruppo (ad esempio archiviando i file di proprietà dell'utente in una directory accessibile solo a root e al gruppo del programma).