Autenticación usando SysRq

3

La idea general aquí es la posibilidad de agregar "avisos de consentimiento" similares a UAC de Windows a un sistema Linux, diseñado de tal manera que no se pueda pasar por alto en el software. Dar consentimiento solo debe ser factible si uno está físicamente en el teclado. Cualquier proceso puede solicitar privilegios elevados.

La idea específica es que un comando que espera una contraseña (como su , o incluso más comandos específicos de la aplicación como gradm , que se usa para autenticar la función de administrador cuando se usa RBAC para controles de acceso) es vulnerable a El proceso local busca las pulsaciones y luego las reproduce. Esto podría mitigarse teniendo un módulo PAM que permita la autenticación cuando se ingresa un SysRq particular o una combinación de teclas similar. El propósito sería dar fe del hecho de que la entidad que solicita privilegios es un usuario físico en el teclado, no un proceso.

El modelo de amenaza

Entiendo que esto no es suficiente para algunos modelos de amenaza, pero es para el mío. Por favor, considere estas afirmaciones a continuación como correctas, a menos que haya un error evidente. El modelo de amenaza es simple:

  • Los procesos malintencionados quieren aumentar los privilegios mediante el secuestro del mecanismo de autenticación.
  • Solo los usuarios autorizados tienen acceso físico. La sola presencia física demuestra autoridad.
  • No hay vulnerabilidades de escalamiento de privilegios que puedan usarse para secuestrar el kernel.
  • El mecanismo de entrada no se puede comprometer, por ejemplo, no hay firmware de teclado actualizable.
  • Clave de atención segura garantiza que no se estén ejecutando procesos maliciosos en un TTY determinado.
  • Las entradas de Syslog no se pueden falsificar. Ignoremos los códigos de control de Unicode por ahora.

Autenticación con SysRq

Como los comandos de SysRq son interceptados por el kernel antes de ser enviados al espacio de usuario, y como los comandos de SysRq no pueden ser inyectados o falsificados sin acceso físico (están diseñados para ser ingresados únicamente a través de un teclado físico, ignorando /proc/sysrq-trigger ), Parece que ciertas operaciones privilegiadas pueden realizarse de manera segura sin autenticación de contraseña. El proceso se vería así:

  1. Un proceso (como su ) necesitaría solicitar privilegios. Esto se podría hacer usando un módulo PAM que comprueba un comando SysRq personalizado. Solo un comando puede solicitar privilegios a la vez. La implementación en sí no importa.
  2. El sistema debe informar al usuario sobre qué comando está solicitando privilegios. Obviamente, esto no debe ser posible de falsificar, por lo que las indicaciones de X11 son correctas. Una solución de ghetto sería iniciar sesión en el syslog. Si el syslog está configurado para imprimirse a sí mismo en un TTY particular, el usuario puede cambiar a ese TTY y usar la Clave de atención segura (SAK). Esto aseguraría que los registros que ven sean genuinos.
  3. El usuario puede optar por permitir privilegios para el comando, ahora que sabe con certeza qué comando está solicitando privilegios. El ingreso de un comando SysRq en particular otorgará permiso.

Parece que la idea de usar SysRq para privilegios mejorados (o más específicamente, deshabilitar mecanismos de seguridad) no es una idea nueva. La nueva funcionalidad kernel lockdown se puede desactivar a través de SysRq-x.

¿Hay algún problema con este mecanismo de autenticación propuesto para mi modelo de amenaza?

    
pregunta forest 06.02.2018 - 04:57
fuente

0 respuestas

Lea otras preguntas en las etiquetas