Alcune domande di base sulla sicurezza del kernel Linux [chiuso]

Non so molto sul kernel Linux e ho alcune domande.

1. Qual è lo scopo principale di separare la memoria del kernel dalla memoria dello spazio utente? Per assicurarsi che un'applicazione utente non possa fare nulla di male al kernel?

2. Quanti modi ci sono per un'applicazione a livello utente per trasferire il controllo al kernel? Quello che posso inventare include (1) invocare una chiamata di sistema, (2) mappare la memoria al kernel (ma penso che mmap () sia anche una chiamata di sistema) e (3) caricare un modulo del kernel (ma immagino lsmod invoca anche alcune chiamate di sistema). Ho ragione? Ci sono altri modi in cui mi sono perso?

3. Quanti modi per attaccare il kernel? Posso avere alcuni brevi dettagli su di loro?

4. Se ottengo il privilegio di root, significa che controllo completamente il kernel? Vale a dire, posso fare quello che voglio con il kernel e l'hardware? O ho ancora un potere limitato sul kernel?

Lo apprezzerei molto se qualcuno potesse aiutarmi a capire la risposta a queste domande.

Proverò a rispondere alle domande il più brevemente possibile. Le domande che poni di solito vengono affrontate nei corsi introduttivi sui sistemi operativi nelle università, ma suppongo che tu non abbia seguito un corso del genere.

1. L'isolamento della memoria per i processi di spazio utente è molto desiderabile, non solo per proteggere il kernel da programmi di spazio utente dannoso, ma anche per proteggere i programmi di spazio utente l'uno dall'altro. Questo è di solito indicato come memoria virtuale . Inoltre semplifica l'implementazione del paging, il che è auspicabile anche per altri motivi (frammentazione più semplice, linker / caricatori più semplici ecc.).

2. Interruzioni (non tutte in controllo di un'applicazione a livello di utente). Rinunciare al processore toglie anche il "controllo" al processo (es wait. Ecc. Che sono anche chiamate di sistema). Il kernel stesso potrebbe decidere di annullare la programmazione di un'applicazione.

3. Questa è una domanda molto ampia. Il kernel con chiamate di sistema mal implementate è vulnerabile. La capacità di scrivere nella memoria fisica sarebbe un altro modo. Esistono altre vulnerabilità che possono derivare da istruzioni mal implementate (ad es. Vulnerabilità sysret nei processori Intel).

4. I privilegi di root non sono gli stessi dei privilegi del kernel. Un'applicazione in esecuzione come utente root sta ancora utilizzando la memoria virtuale, deve ancora effettuare chiamate di sistema, deve ancora obbedire alle altre regole che qualsiasi applicazione a livello utente deve.

Se vuoi che fornisca maggiori dettagli su alcune delle risposte, fammi sapere.

Se qualcuno può migliorare alcune delle risposte, non esitare a segnalarlo.