Postfix master in esecuzione come root

Il processo Postfix master è quello che avvia gli altri daemon. In particolare, lancia il demone che consegna la posta localmente; quest'ultimo deve essere in grado di impersonare qualsiasi ID utente nel sistema, il che implica iniziare la sua vita come root . Pertanto, è in gran parte inevitabile che il processo principale venga eseguito come root; altrimenti, non funzionerebbe affatto.

Inoltre, il "rischio" coinvolto nell'esecuzione di cose come root è spesso sovrastimato. Per esempio, sul mio server, quello che temo di più è che la mia macchina sarebbe sovvertita e usata come relè per attaccare altre persone. Se un utente malintenzionato ottiene l'accesso come root o solo un accesso "normale utente" non cambia molto le cose a tale riguardo.

C'è un'abitudine diffusa di trasformare i daemon root in demoni non-root, e quindi di rallegrarsi del "miglioramento della sicurezza". Il miglioramento è reale nello scenario mainframe , dove molti utenti hanno account di shell sulla stessa macchina e l'attacker è uno di questi utenti, intento a ottenere l'accesso ai file di altri utenti. Tuttavia, il modello del mainframe è in gran parte scomparso (un tempo era diffuso nelle università, ma oggigiorno ogni studente ha il proprio computer con cui giocare). Quando le macchine sono "personali" (ad esempio, si dispone di un proprio server e nessun individuo ostile ha un account su di esso), i benefici dell'esecuzione di alcuni daemon sotto un UID non root sono minimi. Non nuoce da solo, ma non giustifica il fatto di andare fuori strada in modi complessi per "riparare i daemon di root".

Ciò che rende sicuri i daemon di Postfix è l'assenza di buffer overflow o vulnerabilità simili; correre come non-root è semplicemente un modo per mitigare le conseguenze nel caso in cui una vulnerabilità fosse presente e sfruttata da un utente malintenzionato; e la mitigazione non guadagna molto quando la macchina non è un mainframe condiviso.

Un server che riceve la posta elettronica e lo consegna agli utenti locali ha bisogno delle autorizzazioni di root per due cose.

• Il componente che ascolta le connessioni in entrata deve associare le porte TCP per SMTP (25 senza SSL, 465 con SSL), perché i numeri di porta inferiori a 1024 sono riservati ai servizi controllati dall'amministratore e il loro collegamento è riservato a root (o processi con la capacità applicabile ad es. su Linux).
• Il componente che recapita la posta elettronica deve essere in grado di richiamare un agente di consegna della posta , come ad esempio procmail o maildrop. Questi programmi eseguono codice arbitrario scelto dall'utente che riceve l'email, quindi devono essere richiamati da un programma che può impersonare qualsiasi utente: il programma di richiamo deve essere eseguito come root.

La parte di Postfix che riguarda l'invio di e-mail non deve essere eseguita come root e non viene eseguita come root. La parte che riguarda la ricezione di email da macchine remote viene eseguita come root perché è necessario.

È possibile eseguire Postfix o altri MTA interamente come utente non root, ma questo include restrizioni:

• L'amministratore deve reindirizzare le connessioni in entrata alla porta TCP a una porta diversa sopra il 1024.
• Sono possibili solo l'inoltro remoto e la consegna diretta a un file di posta, non l'invocazione di un MDA. Inoltre, la consegna locale richiede che i file delle cassette postali siano scrivibili dal componente di consegna; questo può essere ottenuto con le autorizzazioni di gruppo.

È sempre meglio eseguire solo processi non di root.

Proprio come un esempio: nel caso in cui il postfix non sia l'unica applicazione importante nel tuo sistema, eseguirlo come root ridurrà il lavoro solo per un avversario, poiché entrando nei processi master del postfix sarà in grado di arrivare ovunque nel vostro sistema (ad esempio, l'accesso a tutte le FS, lo scarico di altri processi con informazioni sensibili in essi, tutti i tipi di cose brutte che fondamentalmente un utente root può fare). Altrimenti, (s) avrà bisogno di trovare / creare un exploit di escalation di privilegi. Anche se il postfix è una singola applicazione, è molto più facile per un avversario rimuovere i log / nascondere la sua presenza nel sistema.

C'è un modo per un processo non-root per collegare le porte sotto 1024:

$ cp -v $(which nc) .
'/bin/nc' -> './nc'

$ ./nc -v -l -p 1025

Listening on [0.0.0.0] (family 0, port 1025)
$ ./nc -v -l -p 25
nc: Permission denied

$ sudo setcap 'cap_net_bind_service=+ep' ./nc

$ ./nc -v -l -p 25
Listening on [0.0.0.0] (family 0, port 25)
Connection from localhost 39964 received!
test

Per ulteriori informazioni, per favore su setcap, fai riferimento a link

Principio del privilegio minimo: link

Il motivo per cui il processo principale deve essere avviato come root è perché solo root può collegarsi a una porta nell'intervallo delle prime 1024 porte "privilegiate".

L'esecuzione di qualsiasi tipo di software come root può essere considerato un thread di sicurezza, ma dipende anche dalla sicurezza del software stesso, e se gli aggiornamenti / patch vengono applicati regolarmente.

Se desideri aggiungere un ulteriore livello di sicurezza puoi prendere in considerazione quanto segue:

1. Configura Postfix per ascoltare su una porta superiore a 1024.
2. Esegui il demone master Postfix come postfix dell'utente.
3. Configurare le tabelle IP per inoltrare TCP / 25 alla porta TCP configurata nel passaggio 1.

Considera anche questo: ti fidi di iptables più di Postfix da un punto di vista della sicurezza?