Esto es asumiendo que escapar del hipervisor es la única forma en que el SO huésped podría comprometer al host, por ejemplo. no está en red, no está compartiendo carpetas o el portapapeles, etc. ¿El conocimiento sobre la contraseña de root del host es importante en el contexto de mantener el aislamiento a través de un hipervisor (escriba uno o dos)?
Para utilizar la contraseña de root, primero se debe escapar el hipervisor.
La contraseña de root solo la usan las aplicaciones de espacio de usuario para solicitar permisos mayores. La forma en que funciona una contraseña de root es simple. Cuando una aplicación quiere cambiar a un usuario más privilegiado, un programa confiable y privilegiado lee la contraseña, la codifica y compara el hash con el hash de la contraseña almacenada en /etc/shadow . Si la contraseña coincide, este programa de confianza ejecuta la aplicación como root. Esta es la razón por la que la contraseña de root se considera confidencial.
Para (ab) usar la contraseña de root, una aplicación maliciosa debe poder realizar syscalls , la API principal entre el espacio de usuario y el kernel. Para usar el programa su para elevar los privilegios, por ejemplo, se necesitan los syscalls execve() y read() para ejecutar el programa y pasarle la contraseña de root, respectivamente. Un sistema operativo invitado que se ejecuta en un hipervisor no tiene acceso a syscalls en el host, solo al propio hipervisor (mediante el llamado hypercalls ), y al kernel que se ejecuta virtualizado. Para escapar del hipervisor, debe explotarse un error en su programación. Por lo tanto, el conocimiento de la contraseña de la raíz del host no ayuda a escapar de un hipervisor porque solo se puede usar para elevar los privilegios después de ¡el hipervisor ya se ha roto!
Si bien el conocimiento de la contraseña de la raíz no facilita el escape del hipervisor, no es necesariamente una buena idea dársela al huésped. Si el hipervisor se ejecuta sin privilegios pero no está en un espacio aislado (por ejemplo, QEMU con sandboxing deshabilitado), un escape del hipervisor puede permitir que el atacante se ejecute con los privilegios del software del hipervisor. Si conocen la contraseña de root, pueden usarla para elevar los privilegios después de que han abandonado el hipervisor.
Sin ninguna otra conectividad con el host (o el mundo exterior), eso no debería ser suficiente para romper por sí solo. Sin embargo, sigue siendo una mala idea; Si la máquina virtual maliciosa se rompe con solo privilegios limitados en el host, podría usar la contraseña de root para elevar sus privilegios. (¿Por qué querría que conozca esa contraseña?).
No es relevante para su pregunta, pero para ser claro:
Tener cualquier contraseña para el host puede permitir que una VM se escape si puede, por ejemplo, SSH en el host (y tener la contraseña de root permitiría que SSH se dirija directamente a root o, si eso está deshabilitado de la forma en que lo está, actualice los privilegios a la raíz después de ingresar como otro usuario). El uso de cualquier otro marco de sesión remota (RDP, VNC, NoMachine, etc.) o de administración remota (DCOM / RPC, Group Policy, Puppet, etc.) también le daría a la VM hostil una vía para escapar del hipervisor, suponiendo que tenga la credenciales y se puede conectar a la máquina correspondiente (generalmente, pero no siempre, al sistema operativo host) en los puertos relevantes.
Lea otras preguntas en las etiquetas password-management isolation