Bloccare l'accesso di rete agli host a livello di kernel in Linux?

"La radice è Dio". Bene, ci sono dei ... e poi ci sono dei elder .

L'utente root può fare molte cose su una macchina. In particolare, può sostituire i file utilizzati per avviare la macchina; quindi, può potenzialmente sostituire il tuo kernel con un altro suo, che gli permetterebbe di passare. SELinux può essere usato come un modo per rendere una radice declassata e neutralizzata che sarà limitata in qualche modo, quindi no più lungo il vero root utente; in particolare, forzare qualsiasi fuga a passare attraverso un riavvio della macchina. Tuttavia, è difficile bloccare tutti i percorsi e, discutibilmente, il kernel Linux e SELinux sono troppo complessi per essere privi di errori - quindi, DEVE esistere exploit locali che consentano almeno root di andare in modalità full-physical.

Inoltre, esistono diversi modi per sfuggire ai filtri di rete. Ad esempio, root potrebbe accedere all'interfaccia di rete a livello ethernet ed emettere e ricevere frame ethernet da solo, ignorando completamente lo stack TCP / IP del kernel, quindi non soggetto a nessun filtro di blocco hanno inserito a quel livello (e, del resto, ignorerebbe anche iptables ).

Per contenere veramente root , provalo con artiglieria pesante. Intendo una Macchina virtuale . Fai girare il sistema Linux in una VM; tutto il traffico di rete esterno da e verso la VM passerà attraverso il sistema di gestione VM, che può quindi bloccare e consentire in qualsiasi modo, come si vede, completamente fuori dalla portata del malvagio root , indipendentemente da ciò che fa. Funzionerebbe anche se il malvagio root sostituisse l'intero sistema con NetBSD o Windows o qualsiasi altra cosa.

La disposizione della VM richiede che la VM sia efficace nel contenere il guest e impedendo che entri in contatto con l'host. Ciò richiede un po 'di fede, ma molto meno di credere che qualcosa di così complesso come SELinux o il sistema di autorizzazione Unix possa raggiungere lo stesso livello di affidabilità dell'isolamento.

Il filtro delle connessioni arbitrarie può essere fatto con un modulo del kernel da hooking netfilter . E qualsiasi cosa fatta nel kernel land con un modulo del kernel, può essere annullata con un modulo del kernel. Inoltre, nulla mantiene la root form semplicemente installando il proprio kernel ...

root è GOD, non dimenticarlo mai.

Quindi la risposta di Rook a te è sì / no. Fondamentalmente senza scaricare il sorgente del kernel Linux e riscrivendone un po 'da solo, ciò che propone è la tua risposta. Potresti fare la maggior parte di ciò che desideri, ma non potresti riuscire a impedire a root di essere in grado di bypassarlo cambiandolo.

Potresti fare in modo che tu abbia un account root che non vede mai la luce del giorno, e un root (come sudo like capabilities) come un account che ha la restrizione e gli viene impedito di cambiarlo.

Oppure potresti avere la tua macchina in modo da avere ogni chroot di login imprigionato in un ambiente subordinato che non potrebbe mai vedere il tuo ambito esterno che ha cambiato il modulo.

Quindi puoi ottenere un po 'di là, ma senza l'implementazione dell'hardware, o qualche riscrittura del sistema operativo, non del tutto.

Rook è corretto, ovviamente. Dato che lo imposteresti come root , qualcuno potrebbe facilmente separarlo come root . Tuttavia, potresti richiedere molto tempo.

L'approccio più diretto sarebbe modificare sys_socket.c , o forse solo socket.c (usermode-wrapper) per includere un filtro IP.

Se modifichi sys_socket.c dovresti ricompilare il kernel, ma qualcuno dovrebbe avviare un kernel diverso per annullare il tuo lavoro, mentre ricompilare socket.c dovrebbe essere un po 'più facile da implementare e annullare.

Tuttavia l'approccio migliore sarebbe quello di acquistare un piccolo firewall IP di base e bloccare gli host su quello.

Root non è dio se hai SELinux abilitato. Questo è l'unico modo in cui posso vedere per realizzare ciò che vuoi. Bloccalo con iptables ed esegui SELinux in modalità rigorosa.

Potresti avere uid 0 ma non avrai le funzionalità (7).