Perché proteggere il kernel Linux dall'utente root?

If an attacker gets root, don't they pretty much own the machine even without kernel access, by doing things like modifying binaries?

Forse, forse no. Con SELinux, puoi limitare l'accesso ai dispositivi a blocco, anche per l'utente root. Quindi, se la partizione di root è di sola lettura (e il sistema è in esecuzione con OverlayFS per fornire modifiche non persistenti), proteggere il kernel da root può garantire uno stato coerente al riavvio, anche se la macchina è stata compromessa livello root.

Se invece il kernel non è protetto dall'utente root, non puoi avere tali garanzie.

Senza un avvio verificato, insieme ai moduli verificati e kexec darai al kernel una migliore possibilità di difendersi dagli attacchi di fronte a un'escalation di privilegi. Di default le due funzioni sono disabilitate:

kexec_load_disabled:

A toggle indicating if the kexec_load syscall has been disabled. This value defaults to 0 (false: kexec_load enabled), but can be set to 1 (true: kexec_load disabled). Once true, kexec can no longer be used, and the toggle cannot be set back to false. This allows a kexec image to be loaded before disabling the syscall, allowing a system to set up (and later use) an image without it being altered. Generally used together with the "modules_disabled" sysctl.

modules_disabled:

A toggle value indicating if modules are allowed to be loaded in an otherwise modular kernel. This toggle defaults to off (0), but can be set true (1). Once true, modules can be neither loaded nor unloaded, and the toggle cannot be set back to false. Generally used with the "kexec_load_disabled" toggle.

Questo non è solo per misure anti-hacking, ma credo anche per una protezione consistency .

Immagina se un utente (anche root) ha modificato qualcosa che lui / lei non dovrebbe avere nel kernel. Può facilmente distruggere il sistema. Pertanto, non è solo per la protezione da malware (anche se le vulnerabilità del kernel sono fondamentali) , ma anche per la coerenza del sistema.

Tuttavia, la root può caricare i moduli del kernel.

Questi moduli hanno funzionalità complete del kernel, sebbene di solito se stessi chiamino funzioni arbitrarie. Ulteriori informazioni su questo qui ...

E sì, fare il root di una macchina equivale a possederlo - non c'è bisogno di hackerare / accedere al kernel. (Fatto divertente: pwn viene dalla parola own )

Uno di questi è virtualizzazione . Non è sempre che l'hardware esegua solo un singolo sistema operativo. Quando si eseguono macchine virtuali, il kernel della VM ha ancora accesso all'hardware in una certa misura o condivide parte della sua memoria con l'host.

L'esempio di rilievo che ricordo è la vulnerabilità di VENOM . Ha usato il driver floppy per uscire dalla macchina guest. Ora, un kernel vulnerabile potrebbe impostare kernel.modules_disabled=1 e non caricare il driver floppy. Inoltre, con l'accesso alla memoria del kernel, qualcuno potrebbe iniettare il driver senza passare attraverso modprobe (sarebbe estremamente difficile ma non impossibile).

Per rispondere alla domanda - forse alcune di queste cose sono effettivamente lì per rendere i rootkit del kernel PIU 'difficili da rilevare e rimuovere. Se ritieni di avere un kernel o anche un rootkit per lo spazio utente, la prima cosa che vuoi fare è scaricare la memoria di sistema in modo da poter cercare un codice insolito. Bene, con il kernel bloccato ora non puoi.

Questo metodo di sicurezza è simile a quello che Microsoft ha fatto per anni. Questo rende gli attacchi difficili e cambia le cose in modo che attacchi specifici non funzionino, ma lascia comunque il sistema molto vulnerabile a qualcuno che sa cosa stanno facendo. Ad esempio, MS ha rimosso il supporto socket raw in XP SP2 in modo che vari strumenti di exploit non funzionassero (per il momento).