In che modo separare le preoccupazioni in processi separati (senza applicazione) aiuta la sicurezza?

Question

In che modo separare le preoccupazioni in processi separati (senza applicazione) aiuta la sicurezza?

#1 da (3 voti)
#2 da (2 voti)

1

In questo talk sulla separazione dei privilegi, Theo de Raadt spiega che ntpd di OpenBSD ha un processo master che chiama settimeofday() , un processo DNS responsabile per l'interrogazione dei server DNS e un processo del protocollo NTP che è responsabile della comunicazione di UDP ai server NTP. Ha questo da dire sul processo DNS:

The other thing we've got is a separate DNS servicer process, cause we wanted to be able to do DNS, but we didn't want the master process to do it because DNS libraries sometimes have bugs, and we didn't want the internet speaker to do it because... it's... it just didn't make sense.

Supponiamo che l'impegno non esista (questo design lo precede, come ho capito io). Ovviamente questo design è piuttosto inutile da solo, come se il servizio di rete fosse compromesso e l'autore dell'attacco sia root sul sistema. Di conseguenza, il processo principale imposterà entrambi i sottoprocessi, che porteranno immediatamente i privilegi a nobody o qualcosa del genere. In questo modo, se c'è un problema di sicurezza nella libreria DNS o nel codice NTP, l'autore dell'attacco non ha accesso in scrittura al file di sistema, alle home directory, ecc.

Tutto ciò ha senso per me. Tuttavia, ciò che non capisco è il motivo per cui la separazione tra i processi DNS e UDP è utile. Non importa quale sia stato compromesso; l'autore dell'attacco è in esecuzione come lo stesso utente in entrambi i casi. Puoi inserire il processo DNS, ad es. un nobody2 utente, ma anche in questo caso, nobody2 sarà altrettanto non privilegiato di nobody .

Con il pegno, il vantaggio è ovvio poiché ad es. il processo DNS può impegnarsi a fare solo query DNS, il che sarebbe dannatamente inutile per un utente malintenzionato. Tuttavia, supponiamo che questo impegno non sia un fattore da quando questo design è stato introdotto prima dell'impegno.

Ci sono dei vantaggi per la sicurezza del design ntpd a tre processi che mi manca? O era solo una decisione progettuale non correlata alla sicurezza (forse considerando la possibilità di un futuro sistema simile a un pegno)?

openbsd privilege-separation principle-of-least-privilege

posta strugee 04.01.2017 - 23:39

fonte

2 risposte

2

Let's assume that pledge doesn't exist (this design predates it, as I understand it). Obviously this design is pretty pointless on its own, as if the network-facing service is compromised the attacker has root on the system.

Anche senza pledge il design non è inutile. Se il servizio di rete è compromesso, l'utente malintenzionato non ha root sul sistema - questo è il punto.

Il processo master genera il processo figlio NTPD, che apre il socket UDP come server NTP (porta 123), quindi il processo figlio rilascia i privilegi .

In questo caso, significa che il processo secondario cambia i suoi ID utente reali, effettivi e salvati come quello dell'utente _ntp .

Il processo principale rimane come root in modo che possa chiamare la chiamata di sistema adjtime(2) quando necessario.

Il processo di rete non è più root , eliminando esattamente il rischio che menzioni. Il processo che è root ha un'interfaccia strettamente controllata (tramite il sistema IMSG) per consentire solo di chiamare adjtime(2) . Quindi un utente malintenzionato che compromette il processo secondario dispone di _ntp privilegi sul sistema. E può solo emettere% chiamate diadjtime(2) sull'host - è necessario che le funzionalità siano inferiori rispetto a un compromesso completo di root .

Vedi questa diapositiva in una discussione sui controlli di sicurezza in OpenBSD per una versione preliminare del design prima di pledge(2) :

risposta data 15.01.2019 - 16:43

fonte

Leggi altre domande sui tag openbsd privilege-separation principle-of-least-privilege

Quali sono le possibili impostazioni di sicurezza di un iPhone iOS per la massima sicurezza possibile? Sicurezza del router di frontiera port forwarding

score 3 · Accepted Answer

(Nota che non conosco nulla del design di OpenBSD ntpd, sto solo rispondendo alla generica domanda sulla separazione dei processi.)

Dalla tua citazione, deduco che la separazione del processo UDP dal processo DNS non era motivata da preoccupazioni per la sicurezza, ma da preoccupazioni architettoniche: "perché ... è ... non aveva proprio senso". Il processo UDP e il processo DNS reagiscono a eventi completamente diversi. Se fossero nello stesso processo, userebbero thread separati (esplicitamente o implicitamente con un ciclo di eventi attorno a una chiamata select ). Poiché il processo UDP e il processo DNS operano in modo indipendente, metterli nello stesso processo complicherebbe la progettazione, quindi per impostazione predefinita sono in processi distinti.

Se il server NTP fosse stato progettato come un singolo processo, il design avrebbe dovuto adattarsi ai diversi modelli di interazione dei sottosistemi. Allora i fili avrebbero avuto un senso. Ma se c'è comunque separazione dei processi, il raggruppamento di sottosistemi non collegati nello stesso processo complica la progettazione.

Tuttavia, ci possono essere benefici per la sicurezza dall'avere processi separati. Un vantaggio è che non tutti gli exploit consentono all'utente malintenzionato di eseguire codice arbitrario. Alcuni exploit permettono solo la corruzione localizzata dei dati, o l'esposizione di alcuni dati segreti, o possono causare un arresto anomalo ma sempre in modo controllato (ad esempio solo un dereferenziamento puntatore nullo e non un dereferenziamento puntatore arbitrario). Anche se una vulnerabilità consente l'esecuzione di codice arbitrario, a volte scrivere un exploit è complicato e rendere gli exploit più complicati acquista il tempo del difensore per correggere il bug e distribuire gli aggiornamenti.

Anche se una vulnerabilità consente l'esecuzione di codice arbitrario in un processo, i meccanismi a livello di sistema operativo potrebbero limitare il processo. Anche prima di pledge , OpenBSD consentiva una restrizione su tutto il sistema operativo su ptrace , che dovrebbe essere abilitata su un server di produzione. Un processo eseguito come nobody non può danneggiare direttamente altri processi se non è in grado di identificarli. L'autore dell'attacco dovrebbe trovare alcuni mezzi indiretti, e mentre le opportunità per il DoS abbondano, una violazione del DNS non consentirebbe al malintenzionato di generare traffico NTP falso, ad esempio (non sarebbe in grado di legare la porta).