Comparación de las características de autorización de privilegios
Varios sistemas operativos de computadoras emplean funciones de seguridad para ayudar a evitar que el software malicioso obtenga privilegios suficientes para comprometer el sistema informático. Los sistemas operativos que carecen de dichas funciones, como DOS , las implementaciones de Windows anteriores a Windows NT (y sus descendientes), CP/M-80 y todos los sistemas operativos Mac anteriores a Mac OS X, solo tenían una categoría de usuario a la que se le permitía hacer cualquier cosa. Con contextos de ejecución separados, es posible que varios usuarios almacenen archivos privados, que varios usuarios usen una computadora al mismo tiempo, para proteger el sistema contra usuarios maliciosos y para proteger el sistema contra programas maliciosos. El primer sistema seguro multiusuario fue Multics , que comenzó a desarrollarse en la década de 1960; no fue hasta UNIX , BSD , Linux y NT a fines de la década de 1980 y principios de la de 1990 que los contextos de seguridad multitarea se incorporaron a las máquinas de consumo x86 .
Introducción a las implementaciones
Microsoft Windows
macOS
Unix y similares
Consideraciones de seguridad
Entrada de usuario falsificada o interceptada
Una consideración de seguridad importante es la capacidad de las aplicaciones maliciosas de simular pulsaciones de teclas o clics del mouse, engañando o falsificando así la función de seguridad para que otorgue a las aplicaciones maliciosas privilegios mayores.
Utilizando un cliente basado en terminal (independiente o dentro de un escritorio/GUI): su y sudo se ejecutan en el terminal, donde son vulnerables a la falsificación de entradas. Por supuesto, si el usuario no estuviera ejecutando un entorno multitarea (es decir, un solo usuario en el shell solamente), esto no sería un problema. Las ventanas de terminal generalmente se representan como ventanas normales para el usuario, por lo tanto, en un cliente inteligente o un sistema de escritorio utilizado como cliente, el usuario debe asumir la responsabilidad de evitar que otro malware en su escritorio manipule, simule o capture la entrada.
Uso de una GUI/escritorio estrechamente integrado al sistema operativo: comúnmente, el sistema de escritorio bloquea o asegura todos los medios comunes de entrada, antes de solicitar contraseñas u otra autenticación, de modo que no puedan ser interceptados, manipulados o simulados:
PolicyKit ( GNOME : indica al servidor X que capture todas las entradas del teclado y del mouse. Otros entornos de escritorio que utilizan PolicyKit pueden utilizar sus propios mecanismos.
gksudo - por defecto "bloquea" el teclado, el mouse y el foco de la ventana, [12] impidiendo que cualquier cosa que no sea el usuario real ingrese la contraseña o interfiera de alguna otra manera con el diálogo de confirmación .
UAC (Windows) : de manera predeterminada, se ejecuta en el Escritorio seguro , lo que evita que las aplicaciones maliciosas simulen hacer clic en el botón "Permitir" o interfieran de alguna otra manera con el cuadro de diálogo de confirmación. [13] En este modo, el escritorio del usuario aparece atenuado y no se puede interactuar con él.
Si la función de "bloqueo" de gksudo o el Escritorio Seguro de UAC se vieran comprometidos o deshabilitados, las aplicaciones maliciosas podrían obtener privilegios de administrador utilizando el registro de pulsaciones de teclas para registrar la contraseña del administrador; o, en el caso de UAC si se ejecuta como administrador, falsificando un clic del ratón en el botón "Permitir". Por este motivo, el reconocimiento de voz también tiene prohibido interactuar con el diálogo. [ cita requerida ] Tenga en cuenta que, dado que el indicador de contraseña de gksu se ejecuta sin privilegios especiales, las aplicaciones maliciosas aún pueden realizar el registro de pulsaciones de teclas utilizando, por ejemplo, la herramienta strace . [14] (ptrace estaba restringido en versiones posteriores del núcleo) [15]
Diálogos de autenticación falsos
Otra consideración de seguridad es la capacidad del software malicioso de falsificar diálogos que parecen solicitudes legítimas de confirmación de seguridad. Si el usuario ingresara sus credenciales en un diálogo falso, pensando que el diálogo es legítimo, el software malicioso sabría la contraseña del usuario. Si se deshabilitara el Escritorio seguro o una función similar, el software malicioso podría usar esa contraseña para obtener mayores privilegios.
UAC solicita la secuencia de atención segura en Windows 11, pidiendo al usuario que presione Ctrl+Alt+Supr primero para ingresar las credenciales, para evitar la suplantación de inicio de sesión.
Aunque no es el comportamiento predeterminado por razones de usabilidad, el UAC puede configurarse para requerir que el usuario presione Ctrl+Alt+Del (conocida como la secuencia de atención segura ) como parte del proceso de autenticación. Debido a que solo Windows puede detectar esta combinación de teclas, requerir esta medida de seguridad adicional evitaría que los diálogos falsificados se comporten de la misma manera que un diálogo legítimo. [16] Por ejemplo, un diálogo falsificado podría no pedirle al usuario que presione Ctrl+Alt+Del, y el usuario podría darse cuenta de que el diálogo es falso. O, cuando el usuario presiona Ctrl+Alt+Del, el usuario sería llevado a la pantalla a la que Ctrl+Alt+Del normalmente lo lleva en lugar de un diálogo de confirmación del UAC. De esta manera, el usuario podría saber si el diálogo era un intento de engañarlo para que proporcione su contraseña a un software malicioso.
En GNOME, PolicyKit utiliza distintos cuadros de diálogo, según la configuración del sistema. Por ejemplo, el cuadro de diálogo de autenticación de un sistema equipado con un lector de huellas dactilares puede tener un aspecto diferente al de un sistema que no lo tiene. Las aplicaciones no tienen acceso a la configuración de PolicyKit, por lo que no tienen forma de saber qué cuadro de diálogo aparecerá y, por lo tanto, cómo falsificarlo. [17]
Consideraciones de usabilidad
Otra consideración que se ha tenido en cuenta en estas implementaciones es la usabilidad .
Cuenta de administrador independiente
su requiere que el usuario conozca la contraseña de al menos dos cuentas: la cuenta de uso regular y una cuenta con privilegios superiores, como root .
sudo , kdesu y gksudo utilizan un enfoque más simple. Con estos programas, el usuario está preconfigurado para que se le conceda acceso a tareas administrativas específicas, pero debe autorizar explícitamente que las aplicaciones se ejecuten con esos privilegios. El usuario ingresa su propia contraseña en lugar de la del superusuario o alguna otra cuenta.
UAC y Authenticate combinan estas dos ideas en una. Con estos programas, los administradores autorizan explícitamente a los programas a ejecutarse con mayores privilegios. A los usuarios que no son administradores se les solicita un nombre de usuario y una contraseña de administrador.
PolicyKit se puede configurar para adoptar cualquiera de estos enfoques. En la práctica, la distribución elegirá uno de ellos.
Sencillez del diálogo
Para otorgar privilegios administrativos a una aplicación, sudo , [18] gksudo y Authenticate solicitan a los administradores que vuelvan a ingresar su contraseña.
Con UAC , cuando se inicia sesión como un usuario estándar, el usuario debe ingresar el nombre y la contraseña de un administrador cada vez que necesita otorgar privilegios elevados a una aplicación; pero cuando inicia sesión como miembro del grupo Administradores, (de manera predeterminada) simplemente confirma o rechaza, en lugar de volver a ingresar su contraseña cada vez (aunque esa es una opción). Si bien el enfoque predeterminado es más simple, también es menos seguro, [16] ya que si el usuario se aleja físicamente de la computadora sin bloquearla, otra persona podría acercarse y tener privilegios de administrador sobre el sistema.
PolicyKit requiere que el usuario vuelva a ingresar su contraseña o proporcione algún otro medio de autenticación (por ejemplo, huella digital).
Guardar credenciales
UAC solicita autorización cada vez que se le llama para elevar un programa.
sudo , [6] gksudo y kdesu no piden al usuario que vuelva a introducir su contraseña cada vez que se los llama para elevar un programa. En lugar de eso, se le pide al usuario su contraseña una vez al inicio. Si el usuario no ha utilizado sus privilegios administrativos durante un cierto período de tiempo (el valor predeterminado de sudo es 5 minutos [6] ), el usuario vuelve a estar restringido a los privilegios de usuario estándar hasta que vuelva a introducir su contraseña.
El enfoque de sudo es un equilibrio entre seguridad y usabilidad. Por un lado, un usuario sólo tiene que introducir su contraseña una vez para realizar una serie de tareas de administrador, en lugar de tener que introducir su contraseña para cada tarea. Pero al mismo tiempo, la superficie de ataque es mayor porque todos los programas que se ejecutan en ese tty (para sudo) o todos los programas que no se ejecutan en una terminal (para gksudo y kdesu) prefijados por cualquiera de esos comandos antes del tiempo de espera reciben privilegios de administrador. Los usuarios conscientes de la seguridad pueden eliminar los privilegios de administrador temporales al completar las tareas que los requieren utilizando el sudo -kcomando when desde cada tty o pts en el que se utilizó sudo (en el caso de pts, cerrar el emulador de terminal no es suficiente). El comando equivalente para kdesu es kdesu -s. No hay una opción de gksudo para hacer lo mismo; sin embargo, la ejecución sudo -kfuera de una instancia de terminal (por ejemplo, a través del cuadro de diálogo Alt + F2 "Ejecutar aplicación", desmarcando "Ejecutar en terminal") tendrá el efecto deseado.
La autenticación no guarda las contraseñas. Si el usuario es un usuario estándar, debe ingresar un nombre de usuario y una contraseña. Si el usuario es un administrador, el nombre del usuario actual ya está completo y solo es necesario ingresar su contraseña. El nombre aún se puede modificar para ejecutarse como otro usuario.
La aplicación solo requiere autenticación una vez y se solicita en el momento en que la aplicación necesita el privilegio. Una vez "elevada", la aplicación no necesita autenticarse nuevamente hasta que se haya cerrado y reiniciado.
Sin embargo, existen distintos niveles de autenticación, conocidos como Derechos. El derecho que se solicita se puede mostrar expandiendo el triángulo que se encuentra junto a "detalles", debajo de la contraseña. Normalmente, las aplicaciones utilizan system.privilege.admin, pero se puede utilizar otro, como un derecho inferior por seguridad o un derecho superior si se necesita un mayor nivel de acceso. Si el derecho que tiene la aplicación no es adecuado para una tarea, es posible que la aplicación deba autenticarse nuevamente para aumentar el nivel de privilegio.
PolicyKit se puede configurar para adoptar cualquiera de estos enfoques.
Cómo identificar cuándo se necesitan derechos administrativos
Para que un sistema operativo sepa cuándo solicitarle autorización al usuario, una aplicación o acción debe identificarse como una aplicación que requiere privilegios elevados. Si bien es técnicamente posible que se le solicite al usuario en el momento exacto en que se ejecuta una operación que requiere dichos privilegios, a menudo no es ideal solicitar privilegios en medio de la finalización de una tarea. Si el usuario no pudiera proporcionar las credenciales adecuadas, el trabajo realizado antes de solicitar privilegios de administrador tendría que deshacerse porque la tarea no podría completarse hasta el final.
En el caso de interfaces de usuario como el Panel de control de Microsoft Windows y los paneles de preferencias de Mac OS X, los requisitos de privilegios exactos están codificados en el sistema para que el usuario vea un cuadro de diálogo de autorización en el momento adecuado (por ejemplo, antes de mostrar información que sólo los administradores deben ver). Los diferentes sistemas operativos ofrecen métodos distintos para que las aplicaciones identifiquen sus requisitos de seguridad:
sudo centraliza toda la información de autorización de privilegios en un único archivo de configuración, /etc/sudoersque contiene una lista de usuarios y las aplicaciones y acciones privilegiadas que esos usuarios tienen permitido utilizar. La gramática del archivo sudoers está pensada para ser lo suficientemente flexible como para cubrir muchos escenarios diferentes, como la colocación de restricciones en los parámetros de la línea de comandos. Por ejemplo, se puede conceder a un usuario acceso para cambiar la contraseña de cualquier persona excepto la cuenta raíz, de la siguiente manera:
pete ALL = /usr/bin/contraseña [Az]*, !/usr/bin/contraseña raíz
El Control de cuentas de usuario utiliza una combinación de escaneo heurístico y "manifiestos de aplicación" para determinar si una aplicación requiere privilegios de administrador. [19] Los archivos de manifiesto ( .manifest ), introducidos por primera vez con Windows XP, son archivos XML con el mismo nombre que la aplicación y un sufijo ".manifest", por ejemplo Notepad.exe.manifest. Cuando se inicia una aplicación, se examina el manifiesto para obtener información sobre los requisitos de seguridad que tiene la aplicación. Por ejemplo, este fragmento XML indicará que la aplicación requerirá acceso de administrador, pero no requerirá acceso sin restricciones a otras partes del escritorio del usuario fuera de la aplicación:
Los archivos de manifiesto también se pueden compilar en el propio ejecutable de la aplicación como un recurso integrado . También se utiliza el escaneo heurístico, principalmente por compatibilidad con versiones anteriores. Un ejemplo de esto es mirar el nombre del archivo ejecutable; si contiene la palabra "Setup", se asume que el ejecutable es un instalador y se muestra un mensaje de UAC antes de que se inicie la aplicación. [20]
El UAC también distingue entre las solicitudes de elevación de un ejecutable firmado y de un ejecutable no firmado; y, en el caso del primero, si el editor es "Windows Vista" o no. El color, el icono y la redacción de las indicaciones son diferentes en cada caso: por ejemplo, se intenta transmitir una mayor sensación de advertencia si el ejecutable no está firmado que si no lo está. [21]
Las aplicaciones que utilizan PolicyKit solicitan privilegios específicos cuando solicitan autenticación, y PolicyKit realiza esas acciones en nombre de la aplicación. Antes de autenticarse, los usuarios pueden ver qué aplicación solicitó la acción y qué acción se solicitó.
es decir, codificar periódicamente las contraseñas privilegiadas; y
almacenar valores de contraseña en una bóveda segura y de alta disponibilidad; y
aplicar la política sobre cuándo, cómo y a quién se pueden revelar estas contraseñas.
Referencias
^ "Descripción general del control de cuentas de usuario". Microsoft . 2006-10-02. Archivado desde el original el 2011-08-22 . Consultado el 2007-03-12 .
^ "Runas". Documentación del producto Windows XP . Microsoft . Consultado el 13 de marzo de 2007 .
^ "Temas básicos (e intermedios) de "RunAs". Blog de Aaron Margosis . Blogs de MSDN. 23 de junio de 2004. Consultado el 13 de marzo de 2007 .
^ "Acerca de PolicyKit". Manual de referencia del lenguaje PolicyKit . 2007. Archivado desde el original el 18 de febrero de 2012. Consultado el 3 de noviembre de 2017 .
^ Miller, Todd C. "Una breve historia de Sudo". Archivado desde el original el 22 de febrero de 2007. Consultado el 12 de marzo de 2007 .
^ abc Miller, Todd C. "Sudo en pocas palabras" . Consultado el 1 de julio de 2007 .
^ "Página de inicio de GKSu".
^ "gksu PolicyKit en la wiki de Gnome".
^ Bellevue Linux (20 de noviembre de 2004). "El comando su de KDE". Archivado desde el original el 2 de febrero de 2007. Consultado el 12 de marzo de 2007 .
^ Canonical Ltd. (25 de agosto de 2007). "GutsyGibbon/Tribe5/Kubuntu" . Consultado el 18 de septiembre de 2007 .
^ Puedes leer más sobre beesu Archivado el 25 de julio de 2011 en Wayback Machine y descargarlo desde Koji
^ "gksu - una página de manual de Linux para Gtk+ su frontend". Archivado desde el original el 15 de julio de 2011. Consultado el 14 de agosto de 2007 .
^ "Indicaciones de control de cuentas de usuario en el escritorio seguro". UACBlog . Microsoft . 2006-05-03 . Consultado el 2007-03-04 .
^ "gksu: bloquear el mouse y el teclado no es suficiente para proteger contra el registro de teclas".
^ "Protección ptrace".
^ ab Allchin, Jim (23 de enero de 2007). "Características de seguridad frente a conveniencia". Blog del equipo de Windows Vista . Microsoft . Consultado el 12 de marzo de 2007 .
^ "Agente de autenticación". 2007. Archivado desde el original el 18 de febrero de 2012. Consultado el 15 de noviembre de 2017 .
^ Miller, Todd C. "Sudoers Manual" . Consultado el 12 de marzo de 2007 .
^ "Prácticas recomendadas y pautas para desarrolladores de aplicaciones en un entorno con privilegios mínimos". MSDN . Microsoft . Consultado el 15 de marzo de 2007 .
^ "Comprensión y configuración del control de cuentas de usuario en Windows Vista". TechNet . Microsoft . Consultado el 15 de marzo de 2007 .
^ "Indicaciones de UAC accesibles". Blog de Windows Vista . Microsoft. Archivado desde el original el 27 de enero de 2008. Consultado el 13 de febrero de 2008 .
