Sì, il kitkit rootkit come descritto in Phrack è uno esempio, che modifica il kernel linux tramite /dev/kmem . In sostanza, gli obiettivi rimangono gli stessi: sostituire le voci nella tabella delle chiamate di sistema per fare ciò che vogliamo che facciano. La differenza è che la modifica viene eseguita tramite /dev/kmem .
Le patch grsecurity / PaX per il kernel includono supporto / configurazione per disabilitare l'accesso a /dev/kmem , /dev/mem e /dev/port - vedere la voce qui .
La differenza tra /dev/mem e /dev/kmem è spiegata qui .
La notevole differenza tra la modifica della memoria in questo modo e il caricamento in un modulo del kernel è l'esposizione dei simboli. La maggior parte dei rootkit del modulo del kernel sono compilati con funzioni static , quindi queste funzioni non vengono esportate dal codice; tuttavia, esistono altre tecniche che potrebbero tradire l'esistenza di un modulo del kernel (la funzione init dovrebbe essere esportabile, ad esempio). Un rootkit che modifica direttamente la memoria del kernel non sarebbe visibile in una scansione dello spazio di indirizzamento del kernel tranne in quello che era cambiato (cioè se si sa dove puntare la tabella syscall e a cosa punta, potresti rilevarlo, a meno che l'autore non sia sufficientemente intelligente da garantire che ulteriori letture di /dev/kmem forniscano gli indirizzi corretti).
Riguardo al fatto che un cattivo possa modificare direttamente la memoria - un processo di root è tecnicamente ancora nello userspace; vale a dire che fa ancora parte dell'anello 3 e non ha la capacità di sfuggire alla sua sandbox di memoria virtuale. L'unica memoria che un processo ring 3 può modificare è il proprio spazio di indirizzamento virtuale, che per quanto riguarda è ciò che la memoria assomiglia a . Un processo ring 3 deve rispettare tutte le regole della memoria marcata; ad esempio, se una pagina è contrassegnata come sola lettura, non può essere modificata da un processo (la CPU rifiuta e dice al sistema operativo). Tuttavia, un processo ring 0 (modalità supervisor cpu) può modificare qualsiasi memoria che gli piace e può spingersi fino a chiedere alla CPU di ignorare lo stato delle pagine di memoria (ad esempio, è possibile ignorare il fatto che le pagine siano di sola lettura).
Quindi quello che sto cercando di ottenere è che un processo di root non ha accesso implicito alla memoria per mezzo di un processo di root - deve comunque chiedere e ottenere tale accesso tramite il kernel. È solo che il kernel obbedirà ciecamente. Quindi una soluzione è usare le patch PaX, facendo in modo che il kernel rifiuti tali richieste.