La maggior parte delle volte, quando si installa un programma dalla sorgente, si consiglia di creare un nuovo utente e un nuovo gruppo e assegnare /usr/local/<myapp>all'utente e al gruppo la proprietà creata di recente.
Perché tale pratica è considerata una buona pratica?
Che cosa migliora?
Esempio: utente mysql / gruppo mysql per il server di database MySQL.
Risposte:
La pratica non è quella di creare un utente e un gruppo per applicazione, ma per servizio. In altri termini, i programmi eseguiti da un utente locale non devono essere installati come utenti diversi da root. Sono demoni , programmi in esecuzione in background e che eseguono richieste in arrivo attraverso la rete o altri mezzi di comunicazione, che dovrebbero essere eseguiti come utenti dedicati.
Il demone viene eseguito come utente dedicato in modo tale che se si comporta male (a causa di un bug, probabilmente innescato da un utente malintenzionato), il danno che può causare è limitato: solo i file di dati del demone sono interessati (a meno che l'attaccante non riesca a trovare un buco radice locale , che può succedere). Ad esempio, il daemon del database mysqldviene eseguito come utente e gruppo dedicato e appartengono mysql:mysqlai file di dati del database ( /var/lib/mysql/*) mysql:mysql.
Si noti che il daemon eseguibile e altri dati statici e file di configurazione utilizzati ma che non devono essere modificati dal daemon non devono appartenere all'utente dedicato; dovrebbero essere di proprietà di root:root, come la maggior parte dei file di programma e di configurazione. Il mysqldprocesso non ha sovrascrittura aziendale /usr/sbin/mysqldo /etc/mysql/my.cnf, quindi questi file non devono appartenere mysqlall'utente o essere scrivibili mysqldall'utente o dal mysqlgruppo. Se alcuni file devono essere leggibili solo dal demone e dall'amministratore, devono 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 posseduti da root:rootè i programmi che vengono richiamati da un utente ma che devono essere eseguiti con privilegi aggiuntivi. 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 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). Le ragioni sono duplici:
Non sono le applicazioni in generale, ma i demoni a cui serve. Il motivo è che il demone può essere eseguito come utente non privilegiato anziché root in modo che se ha una vulnerabilità di sicurezza e sia compromesso, il danno che può essere fatto è contenuto solo nelle aree a cui l'utente ha accesso.
La ragione per cui è considerata una buona pratica è quella di impedire ad altri utenti del sistema di sovrascrivere i dati e i file di configurazione per la particolare applicazione.
A titolo di esempio mysql/ mysqlessere il proprietario del deposito per file di database mysql impedisce a chiunque non utilizzando l'API dell'applicazione di danneggiare i database. Inoltre l'utente di mysqlsolito non ha una vera shell, quindi nessuno può accedere come quell'utente.
/usr/bin/atproprietà di daemon/daemonUbuntu
atnon è un demone. È setuid in daemonmodo che possa comunicare con il atddemone tramite file privati.
La creazione di un nuovo gruppo / utente per un nuovo demone installato migliora la sicurezza. Quando il processo del server viene eseguito con tale utente, è limitato ai diritti di accesso di tale utente. In confronto: quando viene eseguito come root può fare tutto.
Questa differenza è importante nel caso in cui il demone sia configurato in modo errato e / o contenga un bug relativo alla sicurezza.
Non sono sicuro di cosa intendi con la seconda parte della tua domanda, ovvero la parte relativa alla /usr/localproprietà. In generale non ha senso che lo stesso utente Xcon cui viene eseguito un demone per motivi di sicurezza possieda anche la directory con i binari (perché in tal caso potrebbe cambiarli in caso di exploit). Ma la directory con i file di dati su cui lavora il demone dovrebbe essere accessibile X- il modo più semplice per configurarlo è quello di rendere Xil proprietario delle directory / dei file di dati.
L'esecuzione di un demone con il proprio utente speciale è solo una tecnica di sicurezza, altre includono una sorta di "chrooting" o l'utilizzo del sistema di controllo dell'accesso obbligatorio (MAC) (ad esempio SELinux).
Questa è una considerazione di sicurezza. Limita il danno che può essere fatto da qualcuno che si rompe in un'applicazione demone. Le applicazioni utente sono generalmente di proprietà di un userid standard come root.
Se il tuo server Web, server di posta e database funzionano tutti come lo stesso utente, è più facile comprometterli. Se uno di essi presenta un bug o un'errata configurazione che consente l'accesso al sistema, tale accesso può essere utilizzato per accedere a tutte e tre le applicazioni.
Se tutti hanno account separati, come raccomandato, è probabile che solo l'applicazione compromessa sia accessibile. Mentre è possibile leggere i dettagli di configurazione pubblica dell'altro, è improbabile che possano essere apportate modifiche.
Molti demoni consentono agli utenti di caricare e scaricare file e altrimenti fanno cose che non vorresti che fossero in grado di fare alle configurazioni per altri demoni. Se ogni applicazione ha il proprio userid e gruppo, è più semplice proteggere i demoni.
Avere un gruppo specifico di daemon rende più semplice concedere in sicurezza un demone accesso sicuro in sola lettura a file e directory. Se il file o la directory sono di proprietà di un altro utente, ma appartengono al gruppo di demoni, di solito saranno accessibili in sola lettura. Le autorizzazioni di accesso possono essere facilmente verificate e corrette con strumenti come find.