Si presume che l'escape dell'hypervisor sia l'unico modo in cui il SO guest potrebbe compromettere l'host-- ad es. non è in rete, non condivide cartelle o appunti, ecc. La conoscenza della password di root dell'host è importante nel contesto del mantenimento dell'isolamento tramite un hypervisor (tipo uno o due)?
Per utilizzare la password di root, l'hypervisor deve prima essere sottoposto a escape.
La password di root viene utilizzata solo dalle applicazioni userspace per richiedere autorizzazioni maggiori. Il modo in cui funziona una password di root è semplice. Quando un'applicazione vuole passare a un utente più privilegiato, un programma fidato e privilegiato legge la password, la blocca e confronta l'hash con l'hash della password memorizzato in /etc/shadow . Se la password corrisponde, questo programma fidato esegue l'applicazione come root. Questo è il motivo per cui la password di root è considerata sensibile.
Per (ab) utilizzare la password di root, un'applicazione malevola deve essere in grado di eseguire syscalls , l'API primaria tra userspace e il kernel. Per utilizzare il programma su per elevare i privilegi, ad esempio, le soglie di execve() e read() sono necessarie per eseguire il programma e passarvi la password di root, rispettivamente. Un sistema operativo guest in esecuzione su un hypervisor non ha accesso ai syscall sull'host, solo all'hypervisor stesso (usando i cosiddetti hypercalls ) e al kernel che è in esecuzione virtualizzato. Per sfuggire all'hypervisor, è necessario sfruttare un bug nella sua programmazione. La conoscenza della password di root dell'host non aiuta quindi a sfuggire a un hypervisor perché può essere utilizzata solo per elevare i privilegi dopo l'hypervisor è già stato rotto!
Sebbene la conoscenza della password di root non renda più semplice la fuga di un hypervisor, non è comunque sempre una buona idea darlo all'ospite. Se l'hypervisor è in esecuzione senza privilegi ma non è in modalità sandbox (ad esempio QEMU con sandboxing disabilitato), l'escape di un hypervisor potrebbe consentire all'utente malintenzionato di eseguire i privilegi del software hypervisor. Se conoscono la password di root, potrebbero usarla per elevare i privilegi dopo che hanno interrotto l'hypervisor.
Senza altra connettività con l'host (o il mondo esterno), questo non dovrebbe essere sufficiente per uscire da solo. È ancora una cattiva idea, però; se la VM malevola esplode con solo privilegi limitati sull'host, potrebbe utilizzare la password di root per elevarne i privilegi. (Perché vorresti che sappia comunque quella password?).
Non pertinente alla tua domanda, ma per essere chiari:
Avere una qualsiasi password per l'host potrebbe consentire a una VM di uscire se può, per esempio, SSH nell'host (e avere la password di root lo consentirebbe a SSH di essere root o, se questo è disabilitato nel modo in cui è di solito, i privilegi di aggiornamento a root dopo essere entrati come altri utenti). L'utilizzo di qualsiasi altra sessione remota (RDP, VNC, NoMachine, ecc.) O di sistemi di gestione remota (DCOM / RPC, Criteri di gruppo, Puppet, ecc.) Darebbe alla VM ostile una via per sfuggire all'hypervisor, assumendo che abbia il relativo credenziali e possono connettersi alla macchina rilevante (di solito, ma non sempre, il sistema operativo host) sulla / e porta / e pertinente / i.
Leggi altre domande sui tag password-management isolation