Domanda:
Programma che richiede che un utente dedicato venga eseguito da solo
XavierStuvw
2020-06-07 13:36:09 UTC
view on stackexchange narkive permalink

Un desktop con Ubuntu Linux 14.04 LTS sembrava andare più lento del solito. top ha mostrato che freshclam, l'utilità di aggiornamento del database per il programma antivirus Unix, stava lavorando più duramente.

freshclam --version mostra che la versione è di ieri:

  ClamAV 0.100.3 / 25835 / Sat Jun 6 14:51:26 2020  

Questo programma era in esecuzione sotto l'utente clamav , invece che root o utente.

  • È normale per un programma richiedere che un profilo utente dedicato venga eseguito da solo?
  • Questo è effettivamente un buon segno, perché aggiunge trasparenza a ciò che accade comunque?
  • Questo è effettivamente un brutto segno, perché un tale un utente ad hoc può intromettersi in altre "cose"?
  • Posso recuperare un elenco dei programmi installati nel mio computer che rivendicano questo diritto di lavorare con un nome utente dedicato? Fondamentalmente, un utente può supervisionare tali comportamenti?

Tutti i suggerimenti di buon senso che si applicano alla comprensione di questo tipo di situazioni sono apprezzati.

tl; dr risposta: 1. Sì.2. Sì.3. No. 4. Sì, controllando / etc / passwd.
A proposito, Ubuntu 14.04 è EOL da oltre un anno.Se ti interessa davvero la sicurezza, devi eseguire l'aggiornamento.
@JosephSible-ReinstateMonica Hai assolutamente ragione, ma i motivi per cui quel computer funziona ancora su 14 spariranno presto.
@JosephSible-ReinstateMonica puoi anche pagare Canonical per il mantenimento della sicurezza esteso, almeno per il breve termine.
@James_pic So che * puoi *, ma non penso che l'OP * sia *.
Cinque risposte:
#1
+80
Moritz Schmitt
2020-06-07 14:03:05 UTC
view on stackexchange narkive permalink

Clamav è un demone. La Linux Standard Base Core Specification raccomanda che i daemon vengano eseguiti con ID utente individuali. In questo modo hai un controllo degli accessi dettagliato per ogni demone e, nel caso in cui uno di essi venga compromesso, l'aggressore non ha automaticamente accesso illimitato al sistema (come farebbe se il demone fosse eseguito come root, ad esempio).

Sì, molti server web e database vengono eseguiti anche dal proprio utente.È abbastanza comune, anche se ci vuole un po 'per abituarsi.Ho visto sistemi con 10-20 "utenti" attivi contemporaneamente.
@Mast Direi che è più che comune, è [buona pratica di sicurezza] (https://en.wikipedia.org/wiki/Principle_of_least_privilege).
#2
+17
mentallurg
2020-06-07 14:19:09 UTC
view on stackexchange narkive permalink

Tutti i suggerimenti di buon senso che si applicano alla comprensione di questo tipo di situazioni

Qualsiasi applicazione necessita di un account per essere eseguita. Eseguire ogni applicazione con un account root può essere pericoloso. Nel caso in cui tale applicazione abbia un bug critico, ad es. consente l'esecuzione di altre applicazioni nel sistema, il successo di possibili attacchi dipende essenzialmente dai permessi di tale applicazione.

Se questa applicazione è in esecuzione con un account root, in realtà tutte le azioni che esegue saranno accettate ed eseguito dal sistema. Significa che un attacco può avere successo. Ma se l'applicazione è in esecuzione con un account limitato con meno autorizzazioni, molte azioni dannose saranno impossibili perché il sistema rifiuterà di eseguirle.

L'utilizzo di un account separato consente di controllare le autorizzazioni necessarie per particolare applicazione più precisamente. Puoi dare a tale account esattamente le autorizzazioni di cui ha bisogno e non di più. Inoltre, puoi ritirare rapidamente le autorizzazioni da tali account o persino eliminarlo. Avere un account separato consente all'applicazione di mantenere i propri dati (file di configurazione, file di registro) protetti da altri utenti senza richiedere l'account di root.

Questa è l'idea.

Nella realtà dobbiamo tenere a mente quanto segue:

1) Può essere che la granularità dei permessi sia troppo grossolana e che tu debba concedere permessi in più di quanto vorresti.

2 ) Mantenere un account separato per ogni applicazione (processo, servizio, daemon) richiede sforzi. Ecco perché stimiamo i rischi e teniamo conto degli sforzi. Se i rischi sono bassi, ha senso mantenere bassi gli sforzi e mantenere il minor numero di account possibile.

3) Molte applicazioni hanno un account utente configurabile con cui verranno eseguite. Ha un nome simile al nome dell'applicazione. Spetta a te mantenerlo o utilizzare un altro account utente per questa applicazione.

4) Riguardo a clamav: avere un account separato non è sospetto, è normale.

Tradizionalmente avevi bisogno di root per ascoltare su porte basse, ma in Linux ragionevolmente moderno, anche Ubuntu 14.04 Trusty, puoi usare CAP_NET_BIND.
Puoi anche eseguire servizi che ascoltano su porte con numeri bassi come utenti non root, tramite il "modo djb".Vedi http://thedjbway.b0llix.net/daemontools/uidgid.html
@dave_thompson_085: Questo è * molto * un buon punto.Ho rimosso la parte sulle porte.Non voglio iniziare qui una discussione sulle capacità rispetto a utenti e gruppi.
@mti2935: L'obiettivo dell'esempio con le porte era mostrare che alcuni obiettivi possono richiedere i permessi di root e l'esecuzione con l'utente root di un processo ottiene effettivamente molto di più di quanto richiesto.L'ho rimosso.
#3
+6
h22
2020-06-07 22:02:41 UTC
view on stackexchange narkive permalink

Le applicazioni spesso eseguono uno script come root durante l'installazione. Questo script può utilizzare i diritti di root per creare l'account utente con limitazioni che dispone solo delle autorizzazioni necessarie per il programma. È un approccio normale e buono.

In caso di dubbio, usa

  ps -e -f  

per vedere la riga di comando in modo completo e verificare dove si trova il binario in esecuzione individuato.

I programmi con un supporto di installazione meno esteso richiedono all'amministratore di creare questi account e script per il passaggio ad essi.

In particolare, questa aggiunta dell'utente avverrebbe come parte dell'installazione del pacchetto "apt".
#4
+5
Peter Green
2020-06-08 09:50:22 UTC
view on stackexchange narkive permalink

È normale che un programma rivendichi un proprio profilo utente per funzionare da solo?

È normale che i programmi eseguiti in background vengano eseguiti come propri utenti.

Questo è effettivamente un buon segno, perché aggiunge trasparenza a ciò che accade comunque?

È buono perché fornisce la separazione dei privilegi, se tutti i programmi in background eseguito come lo stesso utente, quindi un compromesso di uno potrebbe diffondersi più facilmente agli altri, aiuta anche con il monitoraggio.

Questo è effettivamente un brutto segno, perché un tale utente ad-hoc può intromettersi su altre cose?

È certamente subottimale che i sistemi unix-like non mantengano una distinzione nei nomi utente tra utenti umani e utenti di sistema, ma è un vecchio design che è molto difficile da usare indietro e correggere :(. Debian ora consiglia un prefisso di sottolineatura per i nomi utente di sistema appena aggiunti, ma non sembra esserci alcun desiderio di provare a cambiare la moltitudine di quelli esistenti. p>

Posso recuperare un elenco dei programmi installati nel mio computer che rivendicano questo diritto di lavorare con un proprio nome utente? Fondamentalmente, un utente può controllare tali comportamenti?

Come regola generale su sistemi simili a Debian, gli utenti di sistema possono essere distinti avendo user-id nell'intervallo da 0 a 999 mentre gli utenti normali lo faranno normalmente hanno ID utente compresi tra 1000 e 59999 (vedere https://www.debian.org/doc/debian-policy/ch-opersys.html per ulteriori dettagli)

In termini di quali programmi utilizzano effettivamente ciascun utente che può essere più difficile da dire, a volte potresti trovarlo in uno script di inizializzazione, file di servizio systemd, cron job ecc. Ma l'avvio di alcuni servizi è root e poi scende al loro utente specifico dopo un certo le attività di inizializzazione privilegiate (per lo più vincolanti a porte TCP / UDP privilegiate) sono state completate.

#5
+3
HiddenWindshield
2020-06-08 08:12:04 UTC
view on stackexchange narkive permalink

È normale che un programma rivendichi un proprio profilo utente per funzionare da solo?

Come menzionato in altre risposte, questo non è un programma normale. È un demone. E, sì, è perfettamente normale che un demone abbia il proprio utente.

Questo è effettivamente un buon segno, perché aggiunge trasparenza a ciò che accade comunque?
Questo è effettivamente un cattivo sign, perché un tale utente ad-hoc può intromettersi in altre cose?

Non è né buono né cattivo. È semplicemente una questione di comodità. Su un sistema Linux, tutti i processi devono avere qualche utente. Non è possibile avere un processo senza un utente. Allora, quale utente? Non root, perché non dovresti mai eseguire nulla come root a meno che non sia assolutamente necessario. Potresti semplicemente scegliere un utente, ma cosa succede se quell'utente viene eliminato? È molto più semplice per l'installatore / gestore di pacchetti / qualunque cosa creare un utente e usarlo.

Detto questo, per alcuni demoni (specialmente quelli relativi alla rete), ci sono alcuni vantaggi in termini di sicurezza. Se qualcuno è in grado di compromettere in remoto un demone di rete, avrà (in teoria) accesso solo ai file a cui il demone era originariamente in grado di accedere, cioè ai file appartenenti a quell'utente.

Posso recuperare un elenco dei programmi installati nel mio computer che rivendicano questo diritto di lavorare con un proprio nome utente? Fondamentalmente, un utente può controllare tali comportamenti?

Cambiare utente è un "diritto" di ogni processo in esecuzione come root. Poiché i daemon vengono (tipicamente) avviati dalla procedura di avvio del sistema, (tipicamente) si avviano come root, quindi sono (tipicamente) liberi di modificare arbitrariamente i propri ID utente. Anche dopo che hanno abbandonato il privilegio di root (se lo fanno, nulla impedisce loro di continuare come root), possono mantenere la capacità di cambiare il loro ID utente se necessario. Quindi no, non esiste un repository centrale di informazioni di cui i daemon cambieranno il loro ID utente all'avvio e quali no.

Tuttavia, esiste una convenzione che gli ID utente inferiori a 1000 siano riservati agli utenti daemon. Quindi potresti cercare in / etc / passwd gli ID utente a basso numero.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...