Sí , es menos seguro que si cambia a la consola de texto e inicia sesión como root directamente.

Prueba 1:

Si ha iniciado sesión como root en un terminal, otro proceso puede enviar comandos a ese terminal.

Prueba de concepto simple:

1. Abra un terminal, colóquelo en la esquina superior izquierda de la pantalla y cambie a la raíz.
2. Abra un segundo terminal que no se superponga con el primero y escriba:

  

$ xdotool mousemove 100 100 click 1 & & xdotool key l & & clave xdotool s & &   clave xdotool KP_Enter

xdotool

Prueba 2:

xinput puede leer todos los trazos del teclado

Utilizar

  

$ xinput list

para identificar la ID de tu teclado y

  

$ xinput test id

para ver qué pulsaciones de teclas se presionan. Esto también mostrará las pulsaciones de tecla de su terminal y revelará su contraseña.

página de manual de xinput

Si su usuario con pocos privilegios ha ejecutado malware bajo sus privilegios, es posible que ese malware haya cambiado la ruta de acceso de sus usuarios y haya creado un ejecutable "su" diferente. Cuando abres un terminal como tu usuario con pocos privilegios, el malvado ahora está primero en tu camino, así que cuando te pide tu contraseña, has perdido el control de la contraseña.

Esto se evitaría si cambia a una consola de texto y se registra como root. Sin embargo, si cambia a un inicio de sesión de consola de texto como usted y su a raíz, está en la misma situación en la que hace esto desde X. Tenga en cuenta que es posible que un malware intercepte ctrl + alt + F1 y lo engañe para que ingrese un nombre de usuario y la contraseña, pero sospecho que esto sería mucho más difícil y puede requerir más privilegios.

También tenga en cuenta que las escaladas de privilegios locales son muy comunes, por lo que una vez que el malware se está ejecutando como cualquier usuario, es posible que ese malware pueda obtener root a través de escaladas de privilegios.

No estoy familiarizado con los internos de Linux en gran medida, así que tome esta respuesta con un grano de sal.

Cuando inicia sesión en el servidor X como un usuario normal, todos los procesos generados son de los privilegios otorgados a ese usuario. Los procesos tienen acceso restringido al sistema, cuya extensión se aplica mediante la configuración del sistema operativo, pero son libres de interactuar con otros procesos del usuario. Debido a esto, el espacio de dirección de la memoria del proceso es accesible, y lo más probable es que lo puedan escribir todos los demás procesos que posee este usuario. Cuando eleva sus privilegios ejecutando el programa su, el proceso primario que se ejecuta como el usuario normal inicia el nuevo subproceso, el hilo, sea lo que sea, el proceso principal.

Teniendo esto en cuenta, es posible imaginar un escenario en el que se realice una inyección de código en este proceso principal, para poder acceder al espacio de memoria interna de ese proceso víctima. Si es así, es teóricamente posible interceptar la sesión y privilegiar el "token" para obtener acceso de root.

Puedo ver esto hecho de dos maneras diferentes: - Establezca un gancho para el lanzamiento de su programa y desvíe el flujo para elevar varios procesos, en lugar de solo el deseado. - Intercepte una sesión activa e inyecte una solicitud para generar o elevar un proceso diferente.

Ambos escenarios requerirán la ejecución de código arbitrario en una máquina víctima, por lo que sería una etapa posterior del compromiso. Podría marcar la diferencia si ejecuta X o no, en un sentido de que un proceso correcto para inyectar podría ser más difícil de conocer, en lugar de la base predeterminada.

En cualquier caso, creo que es factible realizar un ataque de este tipo, pero el código para hacerlo tendría que ser bastante específico, y, a menos que sea víctima de una campaña de APT, las posibilidades de que alguien saque su raíz caja robando su comando 'su -' están cerca de ninguno.

No tengo conocimiento práctico de cómo manejar un truco de este tipo en Linux, por lo que si me equivoco con respecto a los puntos anteriores, siéntase libre de corregirme.

El uso de root (en el terminal) en una cuenta de nivel de usuario puede darle datos inseguros que pueden resultar en la explotación de malware en la explotación de terminales cruzados. Entonces, básicamente solo usamos acceso de root completo.

Cambiar a root en una cuenta de nivel de usuario es algo muy difícil de hacer. Por lo tanto, es mejor que cambie a la raíz cada vez que inicie sesión simplemente con - >

Primero edite el archivo /etc/login.defs y elimine el comentario de la siguiente línea (quite el '#' al frente):

NO_PASSWORD_CONSOLE tty1:tty2:tty3:tty4:tty5:tty6

Debe hacerlo para que no le pida una contraseña una vez que inicie sesión.

Segundo, edita / etc / inittab. Este archivo es un poco complicado por lo que ayuda si está familiarizado con él, pero si no está trabajando en la siguiente línea:

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

Quiere decirle al programa agetty que ejecute un programa de inicio de sesión automático (escribiremos esto a continuación). Reemplace la línea de arriba con la siguiente:

c1:12345:respawn:/sbin/agetty -n -l /usr/sbin/autologin 38400 tty1 linux

El programa / usr / sbin / autologin no viene con su sistema, debe escribirlo y compilarlo usted mismo, pero es bastante fácil. Primero cree un archivo de texto vacío y agregue el siguiente contenido:

int main() 
{
  execlp( "login", "login", "-f", "shafiq", 0);
}

Reemplace shafiq con el nombre del usuario que desea iniciar sesión automáticamente y guarde el archivo como autologin.c.

Luego compile el programa de esta manera (debe ser root para que funcione):

cc autologin.c -o /usr/sbin/autologin

Y eso es todo. Cuando la máquina termine de iniciarse, se ejecutará el programa de inicio de sesión automático que iniciará sesión como el usuario que especificó en autologin.c y, debido a que editó /etc/login.defs, no le pedirá una contraseña.

Ahora, para ejecutar un programa después de iniciar sesión, simplemente edite .bash_profile en el directorio de inicio del usuario (cree el archivo si no existe) y agregue el comando que desea ejecutar al final de ese archivo, por ejemplo, este es mi .bash_profile, todo lo que hace es ejecutar pico:

pico

Y si no se siente seguro de hacer esto, intente cifrar su BIOS durante el arranque. Y veamos si alguien puede abrir su dispositivo incluso en la etapa inicial de arranque de cualquier dispositivo que esté usando.

Saludos.

Sí, sería más seguro abrir una nueva consola e iniciar sesión como root. Cuando usa su - está canalizando una sesión de root a su sesión normal de usuario. Si hubiera un atacante que tuviera acceso de shell a su cuenta normal, podría secuestrar esa sesión que tiene con root. Es posible que no pueda secuestrar la sesión X, sin embargo, podría secuestrar la conexión entre el usuario normal y el usuario root.