Eseguire il codice nello "spazio del kernel" significa eseguirlo nello spazio dell'anello 0. In altre parole, è la definizione rigorosa di "avere il controllo totale".
L'unica eccezione sarebbe se si esegue un hypervisor. In tal caso, l'esecuzione del codice nell'anello 0 del sistema operativo virtualizzato ti darebbe "solo" il pieno controllo del dispositivo virtualizzato, non dell'hypervisor (che si dice sia in esecuzione nell'anello -1) su cui è in esecuzione. Avresti bisogno di un exploit di fuga separato per arrivarci.
Ciò darebbe a un utente malintenzionato il controllo completo sul telefono? Ad esempio, potrebbero installare un keylogger o altro malware?
Questo è possibile. Poiché tutti i controlli delle autorizzazioni (ad esempio l'accesso ai file, l'accesso alla tastiera...) vengono eseguiti all'interno del kernel, il codice in esecuzione all'interno del kernel potrebbe invocare le azioni necessarie semplicemente direttamente senza eseguire questi controlli.
Consentirebbe a un dispositivo compromesso di eseguire un attacco OTA su altri dispositivi allo stesso modo (diventando un worm)?
Potrebbe essere possibile che alcune azioni richiedano l'accesso al kernel, come la capacità di creare pacchetti di rete manipolati che possono essere utilizzati per compromettere un dispositivo diverso. Ma questo non significa che hai sempre bisogno dell'accesso al kernel per tali attacchi, cioè l'accesso root è di solito sufficiente e talvolta anche un normale processo utente può farlo, a seconda dell'attacco esatto.
Queste preoccupazioni sono mitigate da altre funzionalità di sicurezza, come SELinux, dm-verity, ecc.?
Una volta che l'attaccante ha accesso al kernel, queste tecniche non aiutano. Ma potrebbero aiutare in modo che l'attaccante non ottenga l'accesso al kernel. Ma se aiutano o meno dipende dall'esatto vettore di attacco. Ad esempio, non aiutano in caso della recente vulnerabilità nel driver di rete Broadcom che potrebbe essere attivata da specifici pacchetti di rete.