Malware que obtiene acceso de root a través de "sudo" y "sudo -s"

Depende de donde reside el malware. Supongamos que quiere decir: algún programa que se ejecuta como usuario y que desea obtener privilegios.

Cebador de seguridad X muy corto

Primero, debes tener en cuenta que X hace algo de control de acceso pero no aísla entre los clientes conectados. Cada cliente conectado a su escritorio puede consultar al servidor para obtener información sobre cualquier otro cliente X e interactuar con él.

Por ejemplo, si ejecuta Skype (o cualquier programa, de código abierto o no) en su escritorio, puede espiar la actividad: listar ventanas, sus títulos, tomar capturas de pantalla, registrar teclas, incluso (con algunos kits de herramientas gráficas) fuera de la estructura de lo que está mostrando actualmente. Entonces, en teoría, puede ubicar si tiene un terminal con un shell raíz abierto, envíe eventos de pulsaciones de teclas para escribir algo allí (aunque no todos los emuladores de terminales obedecen a estos).

En la práctica, usted puede notar la simulación de pulsaciones de teclas (ve que sucedió algo, o tal vez el programa podría simplemente cerrar la ventana después de hacer el trabajo para ocultarlo), mientras que el registro de teclas simple es invisible (especialmente) si el programa está autorizado para comunicarse con el mundo exterior a través de una conexión encriptada (mensajería instantánea, programas de audio y video, por ejemplo, que incluye Skype, Google Talk, Flash y otros complementos).

Referencia: Blog de The Invisible Things Lab: The Linux Security Circus: Sobre el aislamiento de GUI

Respuestas a tus preguntas.

En situación 1 , básicamente confías en iotop, pero creo que ese no es tu punto. Imaginemos un malware conectado a su escritorio o ejecutándose como su usuario. Podría intentar engañar a iotop para que haga algo desagradable (simulando las pulsaciones de teclas, etc.) pero probablemente no sea efectivo.

En situación 2 , el shell está separado de X, por lo que es mejor para la seguridad. Debe saber que un programa que se ejecuta con su cuenta de usuario puede escribir en una consola virtual de Linux en la que está conectado, pero solo está insertando caracteres en la pantalla, no en la actividad del proceso. AFAIK no puedes engañar a un programa para que escriba algo en otra consola virtual de Linux.

Situación 3 es lo que se explicó anteriormente. Un programa podría notar eso, escribe algunos comandos e intenta ocultar el hecho.

Si está realmente preocupado, probablemente esté interesado en la seguridad por aislamiento y Qubes .

Ver alguna respuesta en otro sitio cree que no usar la cuenta raíz aumenta la seguridad, estoy publicando esto.

Con la configuración de tiempo de espera predeterminada, hay una manera fácil de obtener privilegios de root agregando esta línea en .bashrc :

trap 'sudo -S touch /hacked </dev/null 2>/dev/null' debug

Creará un archivo hacked en el directorio raíz una vez que el usuario haya usado sudo .

Un hack completo también podría modificar el comando trap para evitar que el usuario lo sepa, y ocultar esas modificaciones modificando set , declare , command , type , etc. Otra opción es modificar sudo en sí mismo.

En teoría, un programa puede matar su panel y escritorio, reemplazándolos con versiones modificadas donde cada entrada a sudo o gksu , etc., o un programa de monitoreo, se reemplaza con otra cosa. El código anterior simplemente lo hizo más fácil. Puede haber soluciones modificando sudo de alguna manera, pero al menos no creo que la contraseña sudo pueda usarse con fines de seguridad en la versión actual.

Una aplicación que se ejecuta como SUDO se ejecutará en una memoria con privilegios y una aplicación que no se ejecute ya que SUDO no podrá acceder al código.

Es posible realizar algún tipo de ataque de inyección contra la aplicación si está mal codificado y utiliza algún otro mecanismo para exponerse fuera del espacio privilegiado, pero no sería trivial hacerlo y tendría que hacerlo. ser específico para esa aplicación.