Todos sus puntos son buenos y tiene razón, pero antes de que nos indignemos debemos recordar cómo funciona el modelo de seguridad de Linux y qué está diseñado para proteger.
Recuerde que el modelo de seguridad de Linux está diseñado pensando en un servidor SSH o solo terminal multiusuario. Windows está diseñado pensando en una estación de trabajo de usuario final (pero he oído que la generación reciente de Windows es más compatible con terminales). En particular, la convención de Linux hace un mejor trabajo al poner las aplicaciones en la zona de pruebas en los usuarios, mientras que en Windows todo lo importante se ejecuta como sistema, mientras que la GUI de Linux (servidor X) apesta a la seguridad, y la GUI de Windows tiene cosas sofisticadas como UAC incorporado. Básicamente, Linux es (y siempre ha sido) primero un servidor y después una estación de trabajo, mientras que Windows es al revés.
Modelos de seguridad
En lo que respecta al "SO" (es decir, el kernel), tiene 7 consolas tty y cualquier cantidad de conexiones SSH (también conocidas como "sesiones de inicio de sesión"); da la casualidad de que ubuntu se envía con scripts para iniciar automáticamente la GUI en el tty7 sesión, pero para el núcleo es solo otra aplicación.
Las sesiones de inicio de sesión y las cuentas de usuario están muy bien separadas entre sí, pero Linux tiene una mentalidad de seguridad que no necesita para proteger a un usuario de sí mismo. En este modelo de seguridad, si su cuenta se ve comprometida por malware, es una causa perdida, pero aun así queremos aislarla de otras cuentas para proteger el sistema en su totalidad.
Por ejemplo, las aplicaciones de Linux tienden a crear un usuario con privilegios bajos como apache o ftp que corren como cuando no necesitan hacer cosas de root. Si un atacante logra tomar el control de un apache en ejecución proceso, puede estropear otros apache procesos, pero tendrá problemas para saltar a ftp procesos.
Tenga en cuenta que Windows adopta un enfoque fundamentalmente diferente aquí, en gran parte a través de la convención de que todas las cosas importantes se ejecutan como Sistema todo el tiempo. Un servicio malicioso en Linux tiene menos posibilidades de hacer cosas malas que un proceso malicioso que se ejecuta como Sistema, por lo que Windows necesita hacer esfuerzos adicionales para proteger a alguien con derechos de administrador de "ellos mismos".
Los entornos GUI y un servidor X que no fue diseñado para la seguridad arrojan una llave en este modelo de seguridad.
Gnome gksudo frente a UAC de Windows y registradores de teclas
En Windows, cuando un proceso de usuario solicita una escalada de privilegios, el núcleo genera un aviso protegido especial cuya memoria y bus de teclado/mouse están aislados del resto del entorno de escritorio. Puede hacer esto porque la GUI está integrada en el sistema operativo. En Linux, la GUI (servidor X) es solo otra aplicación y, por lo tanto, las solicitudes de contraseña pertenecen al proceso que las invocó, ejecutándose como usted, compartiendo permisos de memoria y un bus de entrada con todas las demás ventanas y procesos ejecutándose como usted.
El indicador de root no puede hacer las cosas sofisticadas de UAC, como bloquear el teclado, porque ya deben ser root o requieren un rediseño total del servidor X (ver Wayland a continuación). Un catch-22 que en este caso es una desventaja de separar la GUI del kernel. Pero al menos está de acuerdo con el modelo de seguridad de Linux.
Si tuviéramos que revisar el modelo de seguridad para tomar medidas drásticas agregando sandboxing entre las solicitudes de contraseña y otros procesos que se ejecutan como el usuario en la misma sesión de GUI, podríamos tener que volver a escribir muchas cosas. Como mínimo, el kernel necesitaría ser consciente de la GUI de modo que sea capaz de crear avisos (no es cierto hoy en día). El otro ejemplo de referencia es que todos los procesos en una sesión de GUI comparten un bus de teclado.
Mírame escribir un keylogger y luego presionar algunas teclas en una ventana diferente :
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
Cualquier proceso que se ejecute como usted puede olfatear la contraseña en el indicador o terminal de otro proceso y luego llamar a sudo en sí mismo (esto se deriva directamente de la mentalidad de "no es necesario protegerlo de usted"), por lo que aumentar la seguridad de las solicitudes de contraseña es inútil a menos que cambiamos fundamentalmente el modelo de seguridad y hacemos una reescritura masiva de todo tipo de cosas.
(vale la pena señalar que Gnome parece al menos aislar el bus del teclado en la pantalla de bloqueo y las nuevas sesiones a través de "Cambiar de usuario", ya que las cosas escritas allí no aparecen en el bus del teclado de mi sesión)
Wayland
Wayland es un nuevo protocolo que pretende reemplazar a X11. Bloquea las aplicaciones de los clientes para que no puedan robar información ni afectar nada fuera de su ventana. La única forma en que los clientes pueden comunicarse entre sí fuera del IPC exterior es a través del compositor que los controla a todos. Sin embargo, esto no soluciona el problema subyacente y simplemente traslada la necesidad de confianza al compositor.
Virtualización y Contenedores
Si trabaja con tecnologías en la nube, probablemente esté saltando de un lado a otro diciendo "¡Docker es la respuesta!". De hecho, puntos brownie para ti. Si bien Docker en sí no tiene la intención de mejorar la seguridad (gracias @SvenSlootweg), apunta al uso de contenedores y/o virtualización como un avance que es compatible con la arquitectura Linux actual.
Dos distribuciones de Linux notables que se crean teniendo en cuenta el aislamiento entre procesos:
SO Qubes que ejecuta aplicaciones a nivel de usuario dentro de varias máquinas virtuales separadas en "dominios de seguridad", como el trabajo, la banca, la navegación web.
Conclusión: Desde la perspectiva de un usuario final, no es descabellado esperar que Linux se comporte de la misma manera que Windows, pero este es uno de esos casos en los que necesita comprender un poco cómo funciona el sistema subyacente y por qué se diseñó de esa manera. . El simple hecho de cambiar la implementación de las solicitudes de contraseña no logrará nada, siempre y cuando sea propiedad de un proceso de su propiedad. Para que Linux obtenga los mismos comportamientos de seguridad que Windows en el contexto de una estación de trabajo con GUI de un solo usuario, se requeriría un rediseño significativo del sistema operativo, por lo que es poco probable que suceda, pero cosas como Docker pueden proporcionar un camino a seguir en un entorno más Linux. manera nativa.
En este caso, la diferencia importante es que Linux está diseñado en un nivel bajo para ser un servidor multiusuario y ellos toman la decisión de no proteger a un usuario de sí mismos, mientras que Windows está diseñado para ser una estación de trabajo de un solo usuario. por lo tanto, debe tener protecciones entre procesos dentro de una sesión de inicio de sesión. También es relevante que en Windows la GUI es parte del sistema operativo, mientras que en Linux la GUI es solo otra aplicación a nivel de usuario.
¿Existe algún mecanismo de seguridad en Linux en general o en Ubuntu en particular que impida que cualquier aplicación muestre un cuadro de diálogo idéntico al del sistema que me pide mi contraseña?
Respuesta rápida:No.
Desde la perspectiva del usuario, no hay garantía de que el indicador provenga del sistema operativo; podría ser cualquier programa malicioso que solo tuviera un permiso limitado para mostrar una ventana y, al solicitar mi contraseña, obtendrá acceso ilimitado a toda la máquina.
Si hay un programa malicioso en la computadora, ni siquiera importa qué programa muestra el cuadro de diálogo.
Si es el programa malicioso, bueno, como se describe en la siguiente oración, ni siquiera necesita mostrarle un cuadro de diálogo. Si es un programa legítimo, el programa malicioso puede "vigilar" la ventana y lo que estás escribiendo allí, en entornos de servidor X (la terminal es mejor).
¿Solución?
Si tiene razones para creer que algún programa no es confiable, haga sandboxing (VM o cosas menores).
De lo contrario, no pedir contraseñas . Ese diálogo es conveniente para los usuarios no técnicos. Si le preocupa la seguridad, o el administrador de una organización o similar, no hay absolutamente ninguna necesidad de mostrar una consulta de contraseña de GUI. Configure los permisos de las cuentas de usuario no root correctamente (sí o no, pero no pregunte), y no use un escritorio como root (por eso, y porque es una tentación usar root más a menudo de lo necesario).
Al solicitar al usuario la contraseña con regularidad, el sistema le enseña al usuario que dar su contraseña del sistema cada vez que alguna aplicación la solicita es algo perfectamente natural.
Como se describe, simplemente no les preguntes. Como administrador, se supone que "sus" usuarios tienen permisos claramente definidos.
Y, sobre las actualizaciones automáticas como administrador de la organización:¿Estás loco? :) En serio, no dejes que muchos clientes de Ubuntu actualicen cosas al azar en momentos aleatorios. ¿Qué hay de las imágenes centrales que usted mantiene y prueba y luego implementa? o en la otra dirección cosas como Ansible?
Completamente independiente de la seguridad, las actualizaciones pueden romper cosas. Por eso.
Yo personalmente siempre cancelo ese diálogo. No porque pudiera ser falso, sino porque podría ser real.
¿Se supone que debo otorgar privilegios escalados a "una aplicación" solo porque lo solicita? No, no lo creo.
Las actualizaciones del sistema están bien, las hago manualmente, pero me molesta que el sistema de informe de errores lo requiera. Mal diseño.