Eliminare i privilegi dopo l'avvio o iniziare come utente non privilegiato?

Question

Eliminare i privilegi dopo l'avvio o iniziare come utente non privilegiato?

#1 da (2 voti)

4

Dato un servizio che richiede l'accesso ad alcuni segreti da un file di configurazione per iniziare, posso immaginare tre approcci:

1) Mantiene il file leggibile solo da root. Avvia il processo come root, leggi i privilegi di configurazione e rilascio.

2) Mantenere il file leggibile solo dall'utente demone, avviare il processo come utente demone.

3) Mantiene il file leggibile solo da root. Avvia il processo come utente daemon con la capacità CAP_DAC_READ_SEARCH e rilasciatelo dopo aver letto la configurazione.

La mia analisi iniziale delle alternative:

Opzione 1

+ Se esiste una vulnerabilità, un utente malintenzionato deve leggere la propria memoria di processo per ottenere dati sensibili (abbastanza difficile?)

- Più complesso a causa della necessità di setuid / setgid

- Se il software viene compromesso prima di rilasciare i privilegi, verrà eseguito come root

Opzione 2

+ più semplice da programmare, rilasciare i privilegi dallo script di init

- Se esiste una vulnerabilità, un utente malintenzionato può leggere dati sensibili dal disco (facile)

Opzione 3

+ Non fornisce mai l'accesso root completo al processo

+ Se c'è un bug, un utente malintenzionato dovrebbe leggere la memoria del processo invece di un solo file

- Molto complesso

- Offre comunque un accesso molto ampio alla lettura di file al di fuori del file di configurazione (come /etc/shadow e simili)

Ci sono altre opzioni da prendere in considerazione, o pro o contro che ho perso? Ci sono dei buoni motivi per gestire il privilegio di abbandonare te stesso invece di lasciarlo gestire dal processo di init?

operating-systems linux hardening privilege-escalation privilege-separation

posta thusoy 19.02.2017 - 06:33

fonte

1 risposta

Leggi altre domande sui tag operating-systems linux hardening privilege-escalation privilege-separation

Quali sono i limiti di sicurezza in Windows? Invio di più indirizzi MAC alla stessa porta su uno switch

score 2 · Accepted Answer

Evita di dare i privilegi del daemon che non ha bisogno, nemmeno per l'avvio. Questo esclude le opzioni 1 e 3. Ciò non significa che devi andare per l'opzione 2 però.

Prima fammi richiamare le basi, nel caso in cui:

Esegui il demone come utente dedicato, che esegue solo questo servizio.
Non permettere al daemon di modificare i suoi file di configurazione. Ciò significa che tutti i file di configurazione devono essere di proprietà di un utente diverso. Al giorno d'oggi il supporto per ACL è onnipresente, quindi avere root o qualche altro utente possedere i file di configurazione e utilizzare un ACL per consentire all'utente o al gruppo del daemon di leggerli.

Che ci sia un vantaggio significativo nell'impedire al demone di leggere i file di configurazione sensibili dopo l'avvio dipende da ciò per cui utilizza i dati sensibili e che altro fa. Se queste sono credenziali che il daemon usa una sola volta durante l'avvio e poi si pulisce dalla memoria, c'è un vantaggio nel rendere impossibile leggerle di nuovo in seguito. Se i dati sensibili rimangono in memoria non c'è molto vantaggio, ma dipende anche il più probabile: un exploit che consente la rivelazione della memoria ma non l'esecuzione arbitraria del codice (ad es. Memoria non inizializzata o puntatore errato - sebbene di solito permetta arbitrariamente esecuzione di codice), o un exploit che consente la divulgazione di file ma l'esecuzione di punti con codice arbitrario (ad es. sanitizzazione di percorsi errati).

Se si decide che la protezione di non consentire al daemon di leggere il file sensibile dopo l'avvio è vantaggiosa, allora lasciare che il sistema init gestisca il rilascio dei privilegi. Aprire il file di configurazione dal processo supervisore, quindi rilasciare il privilegio associato (un gruppo supplementare, presumibilmente) e passare il descrittore del file al processo ( --sensitive-config-fd=3 o --sensitive-config-file=/dev/fd/3 ).