Comparación de las características de autorización de privilegios

Una consideración importante en materia de seguridad es la capacidad de las aplicaciones maliciosas para simular pulsaciones de teclas o clics del ratón, engañando o suplantando así la función de seguridad para que otorgue a las aplicaciones maliciosas mayores privilegios.

• Al usar un cliente basado en terminal (independiente o integrado en un entorno de escritorio/GUI): `su` y `sudo` se ejecutan en la terminal, donde son vulnerables a la suplantación de entrada. Por supuesto, si el usuario no estuviera trabajando en un entorno multitarea (es decir, un solo usuario en la consola), esto no sería un problema. Las ventanas de terminal generalmente se muestran como ventanas normales para el usuario; por lo tanto, en un cliente inteligente o un sistema de escritorio utilizado como cliente, el usuario debe responsabilizarse de evitar que otro malware en su escritorio manipule, simule o capture la entrada.
• Utilizando una interfaz gráfica de usuario (GUI) o un entorno de escritorio estrechamente integrado al sistema operativo: Normalmente, el sistema de escritorio bloquea o protege todos los medios de entrada habituales antes de solicitar contraseñas u otra autenticación, de modo que no puedan ser interceptados, manipulados o simulados.

• PolicyKit ( GNOME - dirige al servidor X para capturar todas las entradas de teclado y ratón. Otros entornos de escritorio que utilizan PolicyKit pueden utilizar sus propios mecanismos.
• gksudo - por defecto "bloquea" el teclado, el ratón y el foco de la ventana, ^{[ 17 ]} impidiendo que cualquier cosa que no sea el usuario real introduzca la contraseña o interfiera de otro modo con el cuadro de diálogo de confirmación .
• UAC (Windows) : por defecto, se ejecuta en el Escritorio seguro , lo que impide que las aplicaciones maliciosas simulen hacer clic en el botón "Permitir" o interfieran de cualquier otra forma con el cuadro de diálogo de confirmación. ^{[ 18 ]} 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 registrando las pulsaciones de teclas para obtener la contraseña del administrador; o, en el caso de UAC si se ejecuta como administrador, simulando un clic del ratón en el botón "Permitir". Por este motivo, también se prohíbe la interacción del reconocimiento de voz con el cuadro de diálogo. Cabe destacar que, dado que la solicitud de contraseña de gksu se ejecuta sin privilegios especiales, las aplicaciones maliciosas aún pueden registrar las pulsaciones de teclas utilizando, por ejemplo, la herramienta strace . ^{[ 19 ]} (ptrace se restringió en versiones posteriores del kernel) ^{[ 20 ]}

Otro aspecto de seguridad a considerar es la capacidad del software malicioso para falsificar cuadros de diálogo que simulan solicitudes legítimas de confirmación de seguridad. Si el usuario introduce sus credenciales en un cuadro de diálogo falso, creyendo que es legítimo, el software malicioso conocerá su contraseña. Si la función Escritorio seguro o similar está desactivada, el software malicioso podría usar esa contraseña para obtener privilegios superiores.

• Aunque no es el comportamiento predeterminado por razones de usabilidad, el UAC puede configurarse para requerir que el usuario presione Ctrl+Alt+Supr (conocida como secuencia de atención segura ) como parte del proceso de autenticación. Dado que solo Windows puede detectar esta combinación de teclas, requerir esta medida de seguridad adicional evitaría que los cuadros de diálogo falsificados se comporten de la misma manera que un cuadro de diálogo legítimo. ^{[ 21 ]} Por ejemplo, un cuadro de diálogo falsificado podría no pedirle al usuario que presione Ctrl+ Alt+Del , y el usuario podría darse cuenta de que el cuadro de diálogo es falso. O, cuando el usuario presionara Ctrl+Alt+Supr, sería llevado a la pantalla a la que normalmente lo lleva Ctrl+Alt+Supr en lugar de un cuadro de diálogo de confirmación de UAC. De esta manera, el usuario podría saber si el cuadro de diálogo era un intento de engañarlo para que proporcionara su contraseña a un programa malicioso.
• En GNOME, PolicyKit utiliza distintos diálogos, dependiendo de la configuración del sistema. Por ejemplo, el diálogo de autenticación para un sistema equipado con un lector de huellas dactilares puede ser diferente al de un sistema sin él. Las aplicaciones no tienen acceso a la configuración de PolicyKit, por lo que no pueden saber qué diálogo aparecerá ni cómo falsificarlo. ^{[ 22 ]}

• su requiere que el usuario conozca la contraseña de al menos dos cuentas: la cuenta de uso normal y una cuenta con privilegios más altos, como root .
• sudo , kdesu y gksudo utilizan un enfoque más sencillo. Con estos programas, el usuario viene preconfigurado con acceso a tareas administrativas específicas, pero debe autorizar explícitamente las aplicaciones para que se ejecuten con esos privilegios. El usuario introduce su propia contraseña en lugar de la del superusuario o de otra cuenta.
• pfexec utiliza "perfiles" en lugar de cuentas de usuario para otorgar privilegios al usuario. ^{[ 15 ]} Cada perfil concede acceso para ejecutar un conjunto específico de comandos y autorizaciones, y se nombra según la función que realiza. (Por ejemplo, un usuario debe poder usar el perfil "Gestión de auditoría" para poder ejecutar /usr/sbin/audity /usr/sbin/auditconfig. ^{[ 16 ]} )
• UAC y Authenticate combinan estas dos ideas en una sola. Con estos programas, los administradores autorizan explícitamente la ejecución de programas con privilegios superiores. 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.

• Para otorgar privilegios administrativos a una aplicación, sudo , ^{[ 23 ]} gksudo y Authenticate solicitan a los administradores que vuelvan a introducir su contraseña.
• Con UAC , cuando se inicia sesión como usuario estándar, el usuario debe ingresar el nombre de usuario y la contraseña de un administrador cada vez que necesite otorgar privilegios elevados a una aplicación; pero cuando se inicia sesión como miembro del grupo Administradores, (por defecto) simplemente confirma o deniega, 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, ^{[ 21 ]} ya que si el usuario se aleja físicamente de la computadora sin bloquearla, otra persona podría acercarse y obtener privilegios de administrador sobre el sistema.
• PolicyKit requiere que el usuario vuelva a introducir su contraseña o proporcione algún otro medio de autenticación (por ejemplo, huella dactilar).

• El Control de cuentas de usuario (UAC) solicita autorización cada vez que se le llama para elevar los privilegios de un programa.
• sudo , ^{[ 7 ]} gksudo y kdesu no solicitan al usuario que vuelva a introducir su contraseña cada vez que se ejecutan para elevar los privilegios de un programa. En cambio, se le pide la contraseña una sola vez al inicio. Si el usuario no ha utilizado sus privilegios de administrador durante un cierto período de tiempo (el valor predeterminado de sudo es de 5 minutos ^{[ 7 ]} ), se le restringen nuevamente los privilegios de usuario estándar hasta que vuelva a introducir su contraseña.

El enfoque de sudo es un compromiso entre seguridad y usabilidad. Por un lado, un usuario solo tiene que introducir su contraseña una vez para realizar una serie de tareas de administrador, en lugar de tener que introducirla para cada tarea. Pero al mismo tiempo, la superficie de ataque es mayor porque todos los programas que se ejecutan en esa 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 preocupados por la seguridad pueden eliminar los privilegios de administrador temporales al completar las tareas que los requieren usando el comando cuando desde cada tty o pts en el que se usó sudo (en el caso de pts, cerrar el emulador de terminal no es suficiente). El comando equivalente para kdesu es . No hay una opción de gksudo para hacer lo mismo; sin embargo, ejecutar fuera de una instancia de terminal (por ejemplo, a través del cuadro de diálogo + "Ejecutar aplicación", desmarcando "Ejecutar en terminal") tendrá el efecto deseado.sudo -kkdesu -ssudo -kAltF2

• La autenticación no guarda las contraseñas. Si el usuario es estándar, debe introducir un nombre de usuario y una contraseña. Si el usuario es administrador, el nombre de usuario ya aparece predefinido y solo necesita introducir su contraseña. El nombre se puede modificar para usar la cuenta de otro usuario.

La aplicación solo requiere autenticación una vez, y esta se solicita cuando necesita el privilegio. Una vez que se le otorgan los privilegios necesarios, la aplicación no necesita autenticarse de nuevo hasta que se cierre y se vuelva a abrir.

Sin embargo, existen distintos niveles de autenticación, conocidos como permisos. El permiso solicitado se muestra al expandir el triángulo junto a "detalles", debajo de la contraseña. Normalmente, las aplicaciones utilizan system.privilege.admin, pero se puede usar otro, como un permiso inferior por motivos de seguridad o uno superior si se requiere un mayor nivel de acceso. Si el permiso de la aplicación no es adecuado para la tarea, es posible que deba autenticarse de nuevo para aumentar su nivel de privilegio.

• PolicyKit puede configurarse para adoptar cualquiera de estos enfoques.