Superusuario o Privilegio Temporal: Cuándo y Cómo Elegir entre root y sudo en Linux

1. La Arquitectura del Control de Acceso en POSIX/Linux

1.a) El modelo de seguridad de UNIX: UID 0 y la barrera del espacio de usuario.

El modelo de seguridad en los sistemas operativos acordes con el estándar POSIX se fundamenta en una distinción tajante e intransigente: la separación entre el espacio de usuario (user space) y el espacio del núcleo (kernel space), gestionada a través de identificadores de usuario (UID, User Identifier).

En este esquema, el núcleo del sistema operativo trata a todos los procesos como entidades que se ejecutan en nombre de un UID específico:

• Usuarios ordinarios (UID ≥ 1000 en sistemas modernos): Sus procesos están restringidos por los permisos DAC (Discretionary Access Control) sobre archivos, conectores de red (sockets) y llamadas al sistema (syscalls). Un usuario ordinario no puede enlazar puertos privilegiados (inferiores al 1024), alterar la tabla de enrutamiento, modificar archivos de configuración del sistema en /etc, ni acceder directamente al hardware o a la memoria de otros procesos.

• El superusuario root (UID 0): En la tradición UNIX, el UID 0 representa la autoridad absoluta. El núcleo exime al proceso con UID 0 de las comprobaciones habituales de permisos de lectura, escritura y ejecución sobre el sistema de archivos. root posee la capacidad implícita de invocar cualquier llamada al sistema crítica: montar sistemas de archivos, cargar módulos del núcleo (insmod), manipular reglas de filtrado de paquetes (iptables/nftables) y finalizar cualquier proceso activo (kill).

La interacción entre el espacio de usuario y el núcleo crea una frontera rígida. Cuando un proceso ordinario requiere realizar una operación privilegiada, debe solicitar al núcleo un cambio temporal o permanente de credenciales (EUID o Effective User ID). La forma en que un sistema operativo gestiona esa transición de credenciales sin comprometer la integridad global determina la solidez de su arquitectura de seguridad.

1.b) De su a sudo: Evolución histórica y filosofía de diseño.

Para comprender los mecanismos actuales de elevación de privilegios, es necesario rastrear la evolución de las herramientas diseñadas para cruzar la barrera del UID 0.

El mandato de su (Switch User / Substitute User)

En las primeras décadas de UNIX, la herramienta primaria para asumir privilegios de administración fue el comando su. Su funcionamiento es directo: un usuario invoca su (o su - para cargar el entorno completo), el programa solicita la contraseña de la cuenta de destino (por defecto, root), verifica el hash almacenado en /etc/shadow y, si es correcto, invoca una llamada al sistema setuid(0), entregando al usuario una shell interactiva con UID 0.

La filosofía detrás de su es la sustitución completa de identidad. Sin embargo, este enfoque presentó serias limitaciones operativas a medida que los sistemas UNIX se expandieron en entornos corporativos y universitarios:

• Compartición de credenciales: Todos los administradores debían conocer la contraseña de root.

• Pérdida de trazabilidad (Accounting): Una vez que un usuario ingresaba a la shell de root, todas las acciones ejecutadas quedaban registradas bajo el nombre root en los diarios del sistema, imposibilitando atribuir un cambio específico a una persona concreta.

• Control omnipotente: No existía punto medio; el usuario obtenía acceso total o ningún acceso.

El nacimiento y la filosofía de sudo (Superuser Do)

Concebido originalmente en 1980 por Robert Coggeshall y Thomas Narten en la Universidad de Colorado en Boulder, y popularizado posteriormente por Todd C. Miller, sudo nació para resolver el problema de la delegación granular en sistemas multiusuario.

La filosofía de diseño de sudo cambió radicalmente el paradigma de autenticación:

• Autenticación delegada: El usuario no necesita conocer la contraseña de root; se autentica utilizando su propia contraseña personal.

• Ejecución acotada: En lugar de abrir una shell interactiva por defecto, sudo fue diseñado para ejecutar un único comando con privilegios elevados y retornar inmediatamente al contexto sin privilegios.

• Auditoría centralizada: Cada invocación a sudo registra de forma transparente el usuario que solicitó el mandato, la hora, el directorio de trabajo y el comando exacto invocado.

• Política basada en reglas: A través del archivo de configuración /etc/sudoers, el administrador puede definir qué usuarios o grupos pueden ejecutar cuáles comandos, en qué máquinas y bajo qué identidades.

1.c) La paradoja de la seguridad frente a la usabilidad en escritorios y servidores.

La evolución de Linux desde las salas de servidores hacia las computadoras personales de escritorio introdujo una tensión fundamental entre la teoría de la seguridad POSIX y la ergonomía del usuario final: la paradoja del acceso administrativo.

El modelo del Servidor Corporativ

En un servidor de producción (multiusuario, expuesto a la red, administrado por equipos multidisciplinarios), la separación de funciones es prioritaria. sudo brilla en este contexto porque permite implementar el Principio de Mínimo Privilegio:

• Un operador de nivel 1 recibe permiso exclusivo para reiniciar el servicio web (sudo systemctl restart httpd).

• Un analista de seguridad puede auditar logs sin capacidad de modificar archivos de configuración.

• Ningún usuario requiere acceso a una shell root completa para sus labores cotidianas.

El dilema del Escritorio Monousuario

Cuando las distribuciones orientadas al consumidor final (como Ubuntu, Linux Mint o configuraciones predeterminadas de escritorio) adoptaron sudo como mecanismo primario, introdujeron una modificación sustancial: el primer usuario creado durante la instalación es añadido automáticamente al grupo sudo o wheel con permisos equivalentes a ALL=(ALL:ALL) ALL.

Esta decisión creó un compromiso de seguridad debatible:

• Reutilización de credenciales: El usuario utiliza la misma contraseña para desbloquear el salvapantallas, autenticarse en el escritorio y ejecutar comandos administrativos mediante sudo.

• Vectores de ataque en la sesión del usuario: Si un proceso malicioso (un script, un binario infectado o un ejecutable descargado del navegador) se ejecuta dentro de la sesión de usuario, puede interceptar la clave de usuario mediante un keylogger local, un binario falso en el $PATH, o simplemente esperar a que el usuario introduzca su contraseña en la terminal para elevar privilegios de forma transparente.

• La "ilusión" de la barrera de seguridad: En instalaciones de escritorio por defecto, el uso de sudo no siempre actúa como una frontera de seguridad infranqueable frente a malware en el espacio de usuario, sino a menudo como un mero mecanismo para prevenir errores tipográficos accidentales.

Por el contrario, el esquema tradicional de su - con una contraseña de root independiente obliga a mantener dos secretos distintos: la clave del usuario (expuesta en el uso diario) y la clave de root (ingresada únicamente para cambios del sistema). Mientras que este último modelo exige un esfuerzo cognitivo mayor y disciplina por parte del usuario, reduce el riesgo de que el compromiso de la cuenta personal resulte inmediatamente en el control total del sistema.

2. Análisis Técnico: Logueo Directo como root (su -)

2.a) Mecánica interna y variables de entorno del Shell interactivo de root.

Asumir la identidad de superusuario de forma directa implica modificar el contexto de ejecución del proceso en el sistema operativo. La forma en que se realiza esta transición determina qué variables de entorno y recursos hereda la nueva shell.

La diferencia fundamental entre su y su - (su -l)

Cuando se ejecuta el comando su sin argumentos adicionales, el binario realiza las siguientes llamadas al sistema:

• Lee la entrada de autenticación mediante la API de PAM (Pluggable Authentication Modules).

• Invoca setgid() y setuid(0) para cambiar las credenciales reales y efectivas del proceso a las del superusuario.

• Genera una subshell con privilegios de root, pero conserva el entorno del usuario original.

Esta conservación del entorno presenta implicaciones de seguridad y estabilidad importantes:

• $PATH no actualizado: La variable $PATH mantiene las rutas del usuario estándar, lo que puede provocar que comandos administrativos no se encuentren o que se ejecuten binarios locales no deseados en lugar de los ubicados en /sbin o /usr/sbin.

• Herencia de $HOME y configuración: La variable $HOME continúa apuntando al directorio personal del usuario que invocó el comando (por ejemplo, /home/usuario), haciendo que aplicaciones que crean archivos de configuración temporales los escriban con propietario root dentro de la carpeta personal del usuario, alterando los permisos de su propio espacio de trabajo.

Por el contrario, el comando su - (o su equivalente su -l / su --login) le indica al sistema que debe iniciar una shell de login completa (login shell):

su -

Durante este proceso, el sistema ejecuta las siguientes acciones:

• Limpieza de variables: Se sale del entorno del usuario que invocó el su – creando un nuevo ambiente shell con sus propios parámetros y variables de ambiente, para evitar la contaminación cruzada de variables de entorno.

• Carga de perfiles del sistema: Lee e interpreta secuencialmente /etc/profile, /etc/bashrc (o el archivo de inicialización equivalente de la shell) y las configuraciones específicas de root ubicadas en /root/.bash_profile o /root/.bashrc.

• Restablecimiento de variables clave:

  • $HOME se establece explícitamente en /root.

  • $USER y $LOGNAME cambian a root.

  • $PATH se reconfigura para incluir las rutas del sistema prioritarias (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin).

  • El directorio de trabajo actual (PWD) cambia automáticamente a /root.

• Al finalizar la sesión con los comandos logout, exit o Ctrl+D se destruye el ambiente shell de root y vuelve al entorno del usuario que invocó el su – exactamente igual que en el momento de la invocación.

2.b) Casos de uso legítimos: Mantenimiento crítico, recuperación ante desastres (Single-User Mode) y tareas de E/S intensivas.

Aunque el principio de mínimo privilegio promueve la restricción de sesiones persistentes de superusuario, existen escenarios técnicos donde el inicio de sesión directo o el uso de una shell interactiva de root es la opción más adecuada o la única disponible.

Modo Monousuario y Mantenimiento de Emergencia (Single-User Mode / Emergency Target)

Durante fallos severos en la secuencia de arranque —como corrupción del sistema de archivos principal, errores críticos en /etc/fstab o fallos en el montaje de volúmenes LVM—, systemd cae en emergency.target o rescue.target e inclusive cuando root invoca el comando init 1 para pasar al Modo Monousuario directamente.

En este estado:

• La infraestructura de red y los servicios de autenticación secundarios (LDAP, Kerberos, PAM sobre red) no están disponibles.

• sudo puede ser inaccesible debido a un sistema de archivos en modo lectura estricta o por corrupción en /etc/sudoers.

• El sistema solicita la contraseña directa del usuario root en la consola física o serie para entregar una shell interactiva que permita ejecutar utilidades de bajo nivel como fsck, xfs_repair o la reconfiguración manual de volúmenes.

Tareas masivas de Entrada/Salida (E/S) y tuberías complejas (Pipes y Redirecciones)

Al ejecutar secuencias de comandos complejas que involucran redirección de flujos estándar o encadenamiento de tuberías con permisos elevados, el comportamiento de sudo puede resultar confuso debido a cómo la shell interpreta las redirecciones.

Por ejemplo, la siguiente orden que pretende escribir como superusuario un 1 en el pseudo-archivo ip_forward falla con error de Permiso denegado:

sudo echo "1" > /proc/sys/net/ipv4/ip_forward

El error ocurre porque la redirección > es procesada por la shell del usuario ordinario antes de invocar a sudo. Solo el comando echo se ejecuta con privilegios elevados, mientras que la escritura en el archivo /proc la intenta hacer el usuario sin privilegios.

Aunque existen alternativas (como echo "1" | sudo tee /proc/...), cuando se deben ejecutar tareas masivas de administración de discos, operaciones con dd, particionamiento en lote, o pipelines complejos que procesan gigabytes de información en el sistema de archivos de sistema, abrir una shell interactiva de root elimina la sobrecarga de intercalar sudo en cada componente de la tubería y previene errores de sintaxis en la redirección.

Actualizaciones profundas del sistema operativo o Kernel

Durante la migración de versión de una distribución (dist-upgrade) o la reinstalación masiva del gestor de paquetes (por ejemplo, reconfigurar librerías base glibc o compilar un núcleo a medida), ejecutar la tarea bajo sudo introduce el riesgo de que el caché del timestamp de sudo expire a mitad del proceso, o de que las librerías necesarias para que el propio binario /usr/bin/sudo funcione sean reemplazadas dinámicamente mientras la tarea aún no termina, bloqueando la elevación de privilegios en mitad de la actualización.

Entornos especializados de auditoría de seguridad, informática forense y Pruebas de Penetración (ej. Kali Linux)

Un caso paradigmático donde el modelo tradicional de separación de privilegios pierde sentido práctico es el uso de distribuciones enfocadas en auditoría de seguridad y pruebas de penetración, como Kali Linux, FIRE, CiborgHawk o Parrot OS (especialmente en sus modalidades Live USB o máquinas virtuales volátiles).

Estos entornos tienen unas características peculiares:

• Naturaleza de las herramientas: La inmensa mayoría de las utilidades de pentesting (como nmap para escaneos SYN crudos, aircrack-ng para inyección de tramas 802.11, wireshark para captura de paquetes a nivel de enlace de datos, o herramientas de manipulación de memoria) requieren acceso directo a sockets RAW, interfaces de red en modo monitor o al hardware del sistema. Ejecutar constantemente sudo frente a decenas de herramientas interactuando simultáneamente introduce una fricción innecesaria.

• Inexistencia de datos críticos locales: Las instancias de auditoría Live están diseñadas como plataformas de ataque o evaluación temporales. No alojan bases de datos corporativas, servicios en producción ni información confidencial del usuario.

• Aceptación del riesgo por diseño: Dado que el sistema no almacena datos sensibles y su vida útil se limita a la duración de la prueba o sesión, el riesgo de compromiso del sistema local es marginal. En este contexto operativo, trabajar permanentemente como root es la postura más práctica y eficiente.

2.c) Los riesgos del superusuario: Ausencia de barreras, ejecuciones accidentales y falta de trazabilidad.

Mantener una sesión interactiva abierta como root expone al sistema a vulnerabilidades operativas y de seguridad que no pueden ser mitigadas por el diseño del sistema operativo, ya que el núcleo asume que todas las órdenes de UID 0 son legítimas.

El sistema ni sospecha ni pregunta, dado que supone que root es un usuario muy sabio que sabe perfectamente lo que le está ordenando.

Por esta razón, en cualquier sistema generalista o de producción, la regla de oro al abrir una sesión interactiva como root es cerrar la shell (exit, logout o Ctrl+D) inmediatamente después de concluir la tarea administrativa que requirió la elevación de privilegios.

Ausencia de barreras y la trampa de los caracteres comodín (Wildcards)

Dentro de la shell de root, no existen confirmaciones de seguridad predeterminadas. Un error de escritura (typo) menor puede provocar consecuencias catastróficas inmediatas:

• Espaciado accidental: Un comando como rm -rf /tmp/app /* (con un espacio involuntario entre app y /*) se traduce en la eliminación no recursiva de /tmp/app/ seguida de la purga destructiva de todo el sistema de archivos raíz (/).

• Expansión inesperada de comodines: Ejecutar chown -R usuario:grupo * dentro del directorio incorrecto puede alterar los permisos de miles de binarios del sistema, dejando el SO en un estado inoperable de forma irreversible.

Contaminación del contexto de trabajo y ejecución no intencionada

Un riesgo frecuente en entornos de escritorio o en servidores donde un administrador mantiene una terminal con root abierta en segundo plano es la pérdida de conciencia de contexto:

• El administrador cree estar en una pestaña con privilegios de usuario estándar e invoca scripts de prueba, comandos de compilación o descargas vía curl/wget.

• Dichos procesos se ejecutan con permisos UID 0, creando archivos temporales o modificando configuraciones con privilegios de superusuario, o peor aún, ejecutando código arbitrario de terceros directamente en el espacio de root.

La quiebra de la trazabilidad y el no repudio (Accounting Failure)

Desde la perspectiva de la auditoría y la seguridad de la información (ISO/IEC 27001, NIST SP 800-53):

• Cuando un usuario accede directamente con su - o vía SSH como root, se pierde la atribución individual de la acción.

• En los archivos de registro (/var/log/secure, /var/log/audit/audit.log o el diario de systemd), únicamente figurará que la cuenta root modificó un archivo, detuvo un servicio o borró una tabla de base de datos.

• Si múltiples administradores comparten o conocen la clave de root, resulta técnicamente imposible determinar quién fue el autor de una modificación específica, destruyendo el principio de no repudio e impidiendo las auditorías post-mortem tras un incidente de seguridad.

Ruptura de la segmentación de red y aplicaciones: Exposición a malware

Uno de los riesgos más graves en la operación continua como superusuario radica en la violacion directa del principio de segmentación y aislamiento de contextos de seguridad.

Cuando un usuario consulta correo electrónico, descarga archivos o navega por Internet utilizando aplicaciones cliente (como navegadores web o gestores de correo) dentro de una sesión con privilegios de root:

• Impacto bajo UID 0 (root): Si el usuario accede a un sitio web malicioso que explota una vulnerabilidad Drive-by Download o descarga e ejecuta un archivo infectado con malware o ransomware, el código malicioso hereda de forma inmediata los privilegios del proceso padre (UID 0). Al no existir barreras de permisos en el núcleo, el virus puede instalar rootkits a nivel de kernel, cifrar la totalidad del sistema de archivos (/, /boot, /usr, /var), modificar binarios del sistema, comprometer la configuración de red y tomar el control total sobre las cuentas de todos los demás usuarios del sistema.

• Impacto bajo un usuario sin privilegios (UID ≥ 1000): Si la misma acción se realiza desde la cuenta de un usuario estándar, la segmentación del sistema de archivos limita de forma drástica el radio de impacto (blast radius). El malware quedará confinado estrictamente al directorio personal (/home/usuario). El código no podrá alterar los archivos binarios del sistema operativo, no podrá escribir en directorios críticos como /etc o /usr/bin, ni podrá infectar los datos de otros usuarios o comprometer la integridad global del sistema.

Esta diferencia operativa demuestra que la restricción de privilegios no solo protege al sistema contra errores humanos intencionales o inadvertidos, sino que actúa como una barrera de segmentación activa que evita que el compromiso de una aplicación expuesta a la red se traduzca en el compromiso total del sistema operativo.

3. Capítulo 3: Análisis Técnico: Elevación Puntual con sudo

3.a) Arquitectura de sudo: Aislamiento de contexto, timestamp_timeout y credenciales.

La herramienta sudo (Superuser Do) opera como un mecanismo de delegación de control de acceso que intercepta la ejecución de comandos para elevar privilegios de forma efímera. A diferencia de su, que altera el contexto de la shell de manera persistente, sudo actúa como un envoltorio (wrapper) de ejecución que aplica políticas de seguridad antes de invocar la llamada al sistema execve().

Mecánica de ejecución y manejo de credenciales

Cuando un usuario invoca un comando precedido por sudo, el proceso realiza la siguiente secuencia técnica:

• Lectura de políticas (/etc/sudoers y /etc/sudoers.d/): Utilizando la librería libsudo, el programa analiza las reglas de autorización para verificar si el usuario emisor (subjet) tiene permiso para ejecutar la orden (object) bajo la cuenta de destino (por defecto, root).

• Autenticación (Interfaz PAM): Si la regla exige autenticación, sudo invoca los módulos PAM del sistema (/etc/pam.d/sudo). Por defecto, el sistema solicita la contraseña del usuario que invoca el comando, no la del superusuario.

• Pérdida de privilegios y cambio de contexto (setuid / setgid): Si la regla se aprueba, sudo realiza el cambio de credenciales reales y efectivas (EUID/EGID) al UID 0, pero establece un entorno limpio para el proceso hijo, eliminando variables peligrosas.

El mecanismo de caché de sesión (timestamp_timeout)

Para evitar que el usuario deba reintroducir su contraseña en cada comando consecutivo, sudo implementa un sistema de almacenamiento en caché de credenciales basado en la directiva timestamp_timeout en /etc/sudoers.

• Funcionamiento interno: Tras una autenticación exitosa, sudo escribe un archivo de marca temporal (ticket) en el directorio /run/sudo/ts/ (o /var/db/sudo/lectured/ según la distribución), firmado con el UID del usuario, el ID de terminal (TTY) y el ID de proceso (PID).

• Comportamiento por defecto: El valor predeterminado de timestamp_timeout suele ser de 15 minutos (15). Durante este intervalo, cualquier invocación posterior a sudo desde la misma terminal reutilizará la firma válida sin solicitar nuevamente la contraseña.

• Control del ciclo de vida del ticket:

  • sudo -k (kill): Invalida la marca temporal actual forzando la solicitud de contraseña en la siguiente invocación.

  • sudo -K (sure kill): Elimina por completo el archivo de ticket del usuario en /run/sudo/ts/.

  • timestamp_timeout=0: Configuración de máxima seguridad que deshabilita el caché, obligando a autenticar cada comando individualmente.

3.b) Ventajas operativas: El Principio de Mínimo Privilegio, accounting (auditd/journald) y segregación de funciones.

La adopción de sudo en entornos corporativos y de producción responde a tres pilares fundamentales de la ingeniería de seguridad de la información:

Principio de Mínimo Privilegio y Segregación de Funciones (SoD)

En lugar de otorgar acceso total a través del UID 0, sudo permite desglosar las tareas administrativas mediante un control de acceso basado en roles (RBAC). A través de alias de usuarios, hosts y comandos en /etc/sudoers, es posible definir perfiles operativos estrictos:

# Permitir que el grupo 'soporte' reinicie solo el servicio web
%soporte ALL=(ALL) /usr/bin/systemctl restart httpd, /usr/bin/systemctl reload httpd

# Permitir a los analistas de logs consultar archivos sin modificar
%analistas ALL=(ALL) NOPASSWD: /usr/bin/journalctl, /usr/bin/tail -f /var/log/httpd/*

Esto garantiza la segregación de funciones: un administrador de bases de datos no requiere acceso a la configuración de la red, ni un operador de monitoreo necesita permisos para alterar las cuentas de usuario.

Trazabilidad y no repudio (Accounting)

A diferencia del logueo directo como root, donde la identidad individual se diluye en el UID 0, sudo intercepta y registra cada llamada en los subsistemas de auditoría del sistema operativo:

• Integración con syslog / journald: Cada comando ejecutado mediante sudo genera un registro en /var/log/secure o en el diario de systemd, almacenando:

  • El usuario real que invocó la orden (PWD y USER).

  • La terminal física o pseudo-terminal (TTY).

  • El directorio desde el cual se emitió el comando (PWD).

  • La identidad asumida (TARGET USER, ej. root).

  • La orden exacta ejecutada con todos sus parámetros.

• Auditoría avanzada con auditd: El demonio de auditoría de Linux (auditd) puede registrar tanto el inicio como la finalización del proceso generado por sudo, enlazándolo al identificador de inicio de sesión de auditoría (auid), el cual se mantiene inalterado incluso si el proceso cambia su UID a 0, garantizando el no repudio.

3.c) Los vectores de ataque en sudo: GTFOBins, secuestro de variables de entorno y abuso del cache de sesión.

A pesar de sus ventajas, una configuración deficiente de sudo puede generar vulnerabilidades críticas que permiten la escalada no autorizada de privilegios (Privilege Escalation).

Abuso de binarios interactivos (GTFOBins)

El error más común en la administración de /etc/sudoers es otorgar permisos sudo sobre binarios que poseen la capacidad intrínseca de invocar subshells o leer/escribir en el sistema de archivos de forma arbitraria.

Por ejemplo, si se concede permiso sudo sobre editores de texto (vim, nano), visores de archivos (less, more), o utilidades como find o python:

• Evasión mediante vim: Si un usuario ejecuta sudo vim /etc/hosts, una vez dentro del editor puede escribir la secuencia :sh o :!/bin/bash. vim (que se ejecuta como UID 0) generará una shell interactiva con permisos totales de root, anulando las restricciones de sudo.

• Evasión mediante find: Ejecutar sudo find . -exec /bin/sh \; -quit invoca un intérprete de comandos directamente como superusuario.

Secuestro de variables de entorno (Environment Hijacking)

Por defecto, las versiones modernas de sudo aplican la directiva env_reset en /etc/sudoers, la cual destruye el entorno de usuario y exporta únicamente un conjunto mínimo de variables seguras. Sin embargo, si un administrador deshabilita esta protección o añade variables peligrosas a env_keep (como PYTHONPATH, LD_PRELOAD o LD_LIBRARY_PATH):

• Un atacante puede forzar a un binario ejecutado vía sudo a cargar bibliotecas dinámicas maliciosas creadas en el espacio de usuario, ejecutando código arbitrario con privilegios de root.

Abuso del Caché de Sesión (Hijacking de la ventana de 15 minutos)

En entornos de escritorio o servidores compartidos, la ventana de tiempo otorgada por timestamp_timeout representa un vector de ataque aprovechable por malware local:

• Si un usuario ejecuta un comando válido con sudo y deja la terminal abierta, un proceso malicioso que se ejecute en segundo plano con sus mismos permisos de usuario puede interactuar con /run/sudo/ts/ o reutilizar la terminal activa para enviar comandos con sudo sin que se le vuelva a solicitar la clave, elevando privilegios dentro de la ventana de tiempo del ticket.

4. Matriz de Decisión: ¿Cuándo usar cada modelo?

4.a) Criterios según el entorno y el análisis de riesgos

La elección entre utilizar la elevación puntual de privilegios mediante sudo o mantener una sesión interactiva persistente como superusuario (su - / root) no debe responder a preferencias personales, sino a una evaluación rigurosa del escenario de uso, el nivel de exposición de los datos y el ciclo de vida del sistema operativo.

Servidor de Producción Multiusuario (Enfoque Enterprise)

• Contexto: Equipos de infraestructura crítica, servidores de bases de datos, nodos de cómputo y servicios web expuestos a la red, administrados simultáneamente por múltiples ingenieros, analistas y operadores.

• Regla rectora: Uso exclusivo de sudo. El acceso directo como root vía SSH debe estar estrictamente bloqueado.

• Justificación: La prioridad es la trazabilidad no repudiable (saber exactamente qué usuario ejecutó qué comando), la segregación de funciones (Principio de Mínimo Privilegio) y la protección contra errores que puedan tumbar servicios críticos en producción.

Premisas críticas de configuración:

Nunca utilizar la configuración de fábrica de sudo.

Quien configure sudo deberá ser un administrador competente y con claro conocimiento de las políticas de seguridad diseñadas por la organización del organigrama de funciones y la jerarquía de cargos.

Deshabilitar PermitRootLogin en /etc/ssh/sshd_config, aplicar env_reset en /etc/sudoers para evitar inyección de variables, y configurar auditoría remota enviando logs a un servidor SIEM en tiempo real.

El modelo colapsa si la regla en /etc/sudoers se define de forma perezosa o genérica (p. ej., otorgando ALL=(ALL:ALL) ALL a grupos completos). Debe ser configurado de manera consciente y explícita por personal técnico competente, aplicando alias de comandos acotados, parámetros restringidos y evitando patrones que permitan ataques de GTFOBins (como autorizar binarios del tipo vim, find, less o python bajo sudo sin envoltorios de seguridad).

Estación de Trabajo de Escritorio (Desktop Monousuario de usuario diestro en tecnología y hardening)

• Contexto: Equipos de uso diario en oficina, laboratorio o residencia, utilizados por administradores de sistemas, desarrolladores o profesionales de TI que requieren realizar tareas cotidianas (correo, navegación, ofimática) y, simultáneamente, tareas de mantenimiento, desarrollo de software, bases de datos o gestión del sistema operativo.

• Regla rectora: Uso exclusivo de una cuenta de usuario sin privilegios para las actividades diarias, empleando sudo (o la delegación gráfica vía Polkit/pkexec) únicamente para tareas puntuales del sistema.

• Justificación: Mantiene un aislamiento efectivo entre la sesión de trabajo diaria y los procesos del sistema operativo. El profesional cuenta con la capacidad técnica para auditar, monitorear y restringir los permisos delegados, asegurando que ante un eventual compromiso del espacio de usuario (/home/usuario), el vector de ataque no pueda escalar a nivel de kernel o alterar componentes críticos del sistema de archivos.

Premisa crítica de configuración: Endurecimiento (hardening) obligatorio e explícito del archivo /etc/sudoers mediante visudo. Se debe separar formalmente la identidad de las credenciales exigiendo la contraseña de root (Defaults targetpw y Defaults runas_default=root), deshabilitar el tiempo de gracia del caché de sesión (Defaults timestamp_timeout=0) y restringir estrictamente la delegación de binarios interactivos (anti-GTFOBins) mediante el uso de sudoedit.

Estación de Trabajo de Escritorio (Desktop Monousuario de usuario final sin conocimientos técnicos)

• Contexto: Equipos de uso personal, residencial o administrativo general operados por personas sin formación técnica en administración de sistemas POSIX/Linux, expuestos constantemente a los vectores de ataque más comunes de la red (navegación web cotidiana, descarga e interacción con archivos adjuntos de correo y consumo de multimedia).

• Regla rectora: Prohibición explícita de desplegar en estos entornos distribuciones (tales como Ubuntu, Linux Mint y sus derivadas) que traigan activado sudo por defecto asignando permisos globales (ALL) a la contraseña del primer usuario creado. La arquitectura del sistema debe basarse en distribuciones que mantengan de origen el modelo estricto de separación de identidades, obligando al usuario a operar diariamente en un entorno sin privilegios y a utilizar su - con una contraseña de root independiente para las tareas de administración ocasionales como: Mageia, Debian GNU/Linux (con instalador Live/Calamares), PCLOS (PCLinuxOS) o MX Linux (en su modo de configuración estricto).

• Justificación: Un usuario sin conocimientos de hardening mantendrá la configuración de fábrica del sistema operativo. Si se instala una distribución con sudo preconfigurado de forma permisiva, la misma clave utilizada para iniciar sesión cotidiana sirve para tomar control total del equipo. Ante un ataque de phishing, la ejecución inadvertida de un script malicioso o un keylogger, el vector de ataque obtiene privilegios de superusuario de manera transparente y sin resistencia técnica, anulando el propósito defensivo de la elevación puntual.

Premisa crítica de configuración: Queda terminantemente prohibido utilizar distribuciones que deleguen privilegios de superusuario utilizando la clave del usuario ordinario. El sistema debe contar con una contraseña de root dedicada, robusta y conceptualmente separada de la cuenta de uso diario. Para tareas de administración que requieran entorno gráfico, se debe confiar exclusivamente en la delegación explícita mediante Polkit/pkexec configurado para solicitar la clave de root (no la del usuario emisor), exigiendo cerrar la sesión de administración inmediatamente al terminar.

Computadores Portátiles Corporativos o cuyo dueño es experto en hardening

• Contexto: Equipos portátiles utilizados por ingenieros, administradores de sistemas, analistas o administrados por el personal corporativo capacitado. Están expuestos a movilidad constante, redes Wi-Fi públicas no confiables y un riesgo elevado de robo o pérdida física del dispositivo. Quien administra el sistema es un experto en hardening.

• Regla rectora: Administración del sistema mediante sudo bajo políticas de hardening estrictas, combinado de forma obligatoria e indispensable con el cifrado completo de disco (Full Disk Encryption – LUKS/dm-crypt). En entornos corporativos el usuario final no tiene permisos de hacer labores de administración más allá de agregar usuarios, cambiar la hora y configurar la red.

• Justificación: Si el equipo es sustraído encendido o en modo de suspensión (suspend-to-RAM), las barreras de autenticación del sistema operativo pueden ser evadidas si la sesión de sudo conserva un ticket activo. En un portátil robado o extraviado, si el disco no está cifrado, el atacante puede extraer la unidad de almacenamiento o iniciar el equipo desde un Live USB para leer toda la información confidencial, ignorando por completo las contraseñas del sistema operativo. El uso de sudo endurecido limita la delegación a procesos específicos y el cifrado de disco protege los datos confidenciales en reposo frente a ataques sin conexión (offline attacks).

Premisa crítica de configuración: Cifrado de particiones con LUKS desde la instalación, clave de administración en la UEFI/BIOS con desactivación de arranque desde medios externos (USB/PXE), bloqueo automático de pantalla por inactividad e inclusión obligatoria de Defaults timestamp_timeout=0 y Defaults targetpw en /etc/sudoers para eliminar la ventana de gracia del caché y exigir la contraseña de root en cada elevación.

Computadores Portátiles para usuarios finales sin conocimientos de administración de Linux

• Contexto: Equipos móviles de uso personal, académico o administrativo general operados por personas sin formación técnica. Se emplean en desplazamientos, cafeterías o viajes para tareas comunes (ofimática, correo, navegación y videoconferencias), estando altamente expuestos a robo físico y a redes inalámbricas inseguras.

• Regla rectora: Implementación obligatoria de cifrado completo de disco (LUKS) desde el instalador gráfico y uso de una cuenta de usuario estándar sin acceso a sudo. Se deben utilizar distribuciones orientadas a usuario final que mantengan de origen la separación estricta de identidades (como Mageia, Debian o PCLOS), prohibiendo el despliegue de distribuciones con sudo permisivo preconfigurado (como Ubuntu o Mint). Toda tarea administrativa debe ejecutarse mediante la clave de root aislada (vía Polkit en la interfaz gráfica o su - en terminal).

• Justificación: En un portátil robado o extraviado, si el disco no está cifrado, el atacante puede extraer la unidad de almacenamiento o iniciar el equipo desde un Live USB para leer toda la información confidencial, ignorando por completo las contraseñas del sistema operativo. Asimismo, si la distribución le otorga al usuario final un sudo ligado a su clave personal de inicio de sesión, el compromiso de la cuenta por phishing o malware expone tanto los datos locales como la integridad del sistema operativo.

Premisa crítica de configuración: Queda terminantemente prohibido utilizar distribuciones que deleguen privilegios de superusuario utilizando la clave del usuario ordinario. El sistema debe contar con una contraseña de root dedicada, robusta y conceptualmente separada de la cuenta de uso diario. Para tareas de administración que requieran entorno gráfico, se debe confiar exclusivamente en la delegación explícita mediante Polkit/pkexec configurado para solicitar la clave de root (no la del usuario emisor), exigiendo cerrar la sesión de administración inmediatamente al terminar.

Seleccionar la opción de cifrado de disco (LUKS) en el instalador gráfico inicial, configurar una clave de BIOS/UEFI para impedir la alteración del orden de arranque, y garantizar que la clave de inicio de sesión diaria del usuario sea conceptual y técnicamente diferente de la clave de root requerida para las tareas de administración.

Entornos de Pruebas de Penetración (Pentesting / Kali / Cyborg Hawk / Parrot OS)

• Contexto: Sistemas dedicados a la evaluación de vulnerabilidades, auditorías de seguridad y simulación de ataques en redes locales o remotas.

• Regla rectora: Operación permanente como root (UID 0).

• Justificación: Las herramientas de auditoría (escáneres de puertos crudos como nmap, utilidades de inyección de tramas 802.11 como aircrack-ng, manipuladores de tráfico como wireshark o exploits de bajo nivel) requieren acceso continuo a sockets RAW y al hardware de red. Dado que la máquina de pentesting es una plataforma de prueba temporal que no almacena información confidencial, corporativa ni sensible, la fricción de ingresar sudo constantemente no aporta ningún valor de seguridad real y ralentiza la operativa.

Premisa crítica de configuración: Aislar completamente el equipo de pentesting en una VLAN o segmento de red dedicado a pruebas, no guardar credenciales personales ni acceder a cuentas de correo/banca desde esta instancia, no almacenar información confidencial ni sensible y restaurar la máquina a un estado limpio (snapshot de VM o reinstalación) tras finalizar el compromiso.

Entornos Live OS (Sistemas Efímeros en Medios Removibles)

• Contexto: Sistemas operativos ejecutados en memoria RAM desde un Live USB o Live CD, utilizados para recuperar sistemas caídos, realizar instalaciones del SO o trabajar de forma segura desde lugares no confiables (ej. un café internet o una computadora alquilada) garantizando un entorno 100% limpio e inmune a la contaminación del equipo huésped.

• Regla rectora: Trabajar directamente como root o usar sudo sin contraseña (NOPASSWD).

• Justificación: La arquitectura del sistema es completamente efímera y volátil. Al apagar o reiniciar la computadora, la memoria RAM se purga y todo el estado del sistema operativo se destruye sin dejar rastro. La persistencia de datos es nula por diseño, lo que invalida los riesgos de infección o persistencia de malware a largo plazo.

Premisa crítica de configuración: Asegurar que el medio USB sea de solo lectura (o no persistente), evitar montar o acceder a los discos duros locales del equipo huésped (para no contaminar el medio ni exponer datos) y realizar un apagado completo antes de retirar el medio ejecutable.

4.b) Tabla comparativa de escenarios operativos

Escenario Operativo	Modelo Recomendado	Vector de Riesgo Principal	Prioridad Defensiva	Exigencia de Auditoría / Accounting
Servidor de Producción / Multi-Admin	sudo exclusivo con reglas acotadas	Movimiento lateral, abuso de privilegios, falta de trazabilidad.	Trazabilidad no repudiable, Mínimo Privilegio (SoD) y cumplimiento normativo.	Alta / Estricta (Registro centralizado en SIEM, CloudTrail, Syslog).
Escritorio Monousuario (Desktop)	Usuario convencional + sudo/Polkit	Ejecución de malware vía web/correo, alteración accidental del SO.	Protección de la integridad del sistema operativo y control de ejecución.	Baja / Local (Logs estándar en /var/log/auth.log o journalctl).
Computador Portátil (Laptop)	Usuario convencional + sudo + LUKS (FDE)	Robo/Pérdida física, interceptación en redes hostiles.	Protección del dato en reposo (Data at Rest) y prevención de accesos físicos offline.	Media (Auditoría local + Telemetría de endpoint/EDR si es corporativo).
Entorno de Pentesting (Kali / Parrot)	Shell interactiva de root (su - / sudo -i)	Compromiso de la herramienta por la red analizada.	Eficiencia en el flujo de trabajo de auditoría e independencia operativa.	Nula / Opcional (Solo registros de sesión local para reporte de auditoría).
Entorno Live OS (Sesión Efímera)	root directo	Contaminación por hardware huésped no confiable.	Aislamiento en RAM, garantía de no persistencia y capacidad de rescate.	Nula (El registro desaparece al reiniciar la máquina).

5. Guía Práctica de Configuración y Hardening

5.a) Endurecimiento de /etc/sudoers: targetpw, alias de comandos y restricción de binarios interactivos.

La edición del archivo /etc/sudoers debe realizarse exclusivamente mediante la herramienta visudo, la cual valida la sintaxis antes de aplicar los cambios para prevenir bloqueos accidentales del sistema. Un entorno endurecido requiere abandonar las concesiones globales e implementar directivas estrictas de restricción:

Uso de la directiva targetpw

Para reforzar la seguridad en entornos monousuario de escritorio o servidores de alta sensibilidad, es posible modificar el comportamiento predeterminado de la autenticación para exigir la contraseña de root en lugar de la del usuario emisor, así como eliminar la ventana del caché de sesión:

Por defecto, sudo solicita la contraseña del usuario que invoca el comando. En esquemas de administración delegada donde se busca validar que el operador conoce la clave de la cuenta de destino (o de la cuenta root) antes de ejecutar la acción, se puede activar la directiva targetpw.

Atención: Al habilitar targetpw, sudo exigirá la contraseña del usuario objetivo (por ejemplo, root), por lo que su uso debe evaluarse cuidadosamente según el modelo de trazabilidad de la organización.

# Inclusión en /etc/sudoers

# Exigir la contraseña del usuario de destino (root) en lugar de la del usuario emisor
Defaults targetpw

# Solicitar la contraseña a la cuenta root
Defaults runas_default=root

# Desactivar el caché de sesión (fuerza la autenticación en cada comando)
Defaults timestamp_timeout=0

# Restablecer el entorno para prevenir inyección de variables
Defaults env_reset

Definición de Alias de Comandos (Command Aliases) y Mínimo Privilegio

Para aplicar el Principio de Mínimo Privilegio, se deben utilizar alias (Cmnd_Alias, User_Alias) para agrupar comandos y usuarios, otorgando únicamente los permisos indispensables.

En lugar de conceder ALL=(ALL:ALL) ALL, se deben estructurar grupos de comandos permitidos mediante Cmnd_Alias. Esto delimita con exactitud qué binarios y parámetros puede ejecutar un grupo de usuarios.

# Alias de comandos permitidos para el equipo de soporte de red
Cmnd_Alias RED_OPS = /usr/sbin/ip, /usr/sbin/nft, /usr/bin/systemctl restart NetworkManager

# Definición de alias para servicios de red y monitoreo
Cmnd_Alias RESTART_WEB = /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
Cmnd_Alias VIEW_LOGS = /usr/bin/journalctl -u nginx --lines=*

# Asignación de permisos acotados
%operadores ALL=(ALL) RED_OPS
%auditores ALL=(ALL) NOPASSWD: LOG_AUDIT

# Alias de comandos de lectura de logs
Cmnd_Alias LOG_AUDIT = /usr/bin/journalctl, /usr/bin/tail -f /var/log/secure

# Asignación a grupo de operadores sin requerir clave para tareas repetitivas
%webops ALL=(ALL) NOPASSWD: RESTART_WEB, VIEW_LOGS

Prevención de Escape de Shell vía Binarios Interactivos (GTFOBins)

Bajo ninguna circunstancia se debe otorgar permiso sudo sobre editores de texto, visores o utilidades que permitan invocar subshells. Para permitir la edición de archivos de configuración sin exponer el ejecutable completo, se debe utilizar la directiva sudoedit (sudo -e).

Uno de los errores más graves en la configuración de sudo es permitir binarios interactivos, editores de texto (como vim, less, find, nmap o python), visores o utilidades que permitan invocar subshells.

Si un usuario ejecuta sudo vim /etc/hosts, puede invocar una shell dentro del editor (:sh o :!/bin/bash) y obtener acceso total como root, burlando los controles definidos.

• Regla de oro: Nunca otorgar acceso sudo directo a editores de texto tradicionales para editar archivos del sistema.

• Uso de sudoedit: Para permitir la edición de archivos específicos sin entregar el binario del editor, se debe emplear sudoedit (o sudo -e).

# Permitir editar únicamente la configuración de red sin otorgar shell
Cmnd_Alias EDIT_NET = /usr/bin/sudoedit /etc/network/interfaces

%sysadmin ALL=(ALL) EDIT_NET

# INCORRECTO: Otorga acceso total a shell interactiva mediante :sh dentro de VIM
# %editores ALL=(ALL) /usr/bin/vim /etc/nginx/nginx.conf

# CORRECTO: Permite editar el archivo sin dar acceso al binario del editor como root
%editores ALL=(ALL) sudoedit /etc/nginx/nginx.conf

5.b) Alternativas modernas en entornos de escritorio: El rol de Polkit (pkexec).

En los entornos de escritorio modernos (GNOME, KDE Plasma), el uso directo de sudo para aplicaciones con interfaz gráfica (GUI) presenta inconvenientes severos de arquitectura.

Ejecutar comandos como sudo gedit o sudo nautilus pasa el contexto gráfico completo a UID 0, creando archivos de configuración propiedad de root dentro de $HOME y exponiendo la pila de renderizado gráfico a exploits.

En entornos gráficos y estaciones de trabajo modernas, sudo presenta limitaciones de integración con la sesión de usuario de D-Bus y la arquitectura del escritorio. Para estos casos, el marco de trabajo estándar de la Linux Foundation es Polkit (anteriormente PolicyKit).

A diferencia de sudo, que opera bajo un modelo de "todo o nada" sobre un binario completo, Polkit actúa como un intermediario de autorización a nivel de sistema que evalúa acciones finas (actions) solicitadas por procesos sin privilegios a través de un demonio central (polkitd).

La arquitectura de Polkit

Polkit (anteriormente PolicyKit) es un marco de trabajo a nivel de sistema operativo para definir y manejar autorizaciones en entornos de escritorio. A diferencia de sudo, que opera a nivel de proceso en la terminal:

• Polkit separa explícitamente el mecanismo de la política.

• Permite que una aplicación sin privilegios se ejecute normalmente como usuario ordinario y solicite autorización puntual al demonio de Polkit solo para la operación específica que requiere privilegios (por ejemplo, formatear una unidad USB en gparted o cambiar la zona horaria).

• Mantiene la interfaz gráfica en el espacio de usuario y ejecuta únicamente la tarea de bajo nivel como root.

Uso práctico de pkexec

Para invocar comandos o herramientas desde la terminal dentro de una sesión gráfica respetando el esquema de Polkit, se utiliza el ejecutable pkexec:

pkexec gparted

La política de autorización para cada acción se define en archivos XML ubicados en /usr/share/polkit-1/actions/ y las reglas personalizadas en /etc/polkit-1/rules.d/.

Ventajas de Polkit sobre sudo en el escritorio

• Granularidad: Permite definir reglas específicas para acciones del sistema (ej. cambiar la zona horaria, montar discos externos o agregar impresoras) sin otorgar privilegios de superusuario sobre todo el sistema.

• Integración con PAM y Display Managers: Invoca cuadros de diálogo nativos de la interfaz gráfica (Gnome, KDE) para solicitar la autenticación cuando es necesario.

• Uso de pkexec: Reemplaza a sudo en la línea de comandos cuando se requiere ejecutar comandos respetando las reglas de Polkit en lugar de la sintaxis monolítica de /etc/sudoers.

Configuración de reglas en Polkit (Archivos .rules)

Las políticas de Polkit se definen en Javascript (en /etc/polkit-1/rules.d/). A continuación se muestra un ejemplo de regla para permitir que los usuarios del grupo wheel gestionen servicios sin ingresar contraseña, pero exigiendo reautenticación para detener servicios críticos:

// /etc/polkit-1/rules.d/10-network-manager.rules
polkit.addRule(function(action, subject) {
 if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" &&
 subject.isInGroup("wheel")) {
 return polkit.Result.YES;
 }
});

5.c) Buenas prácticas de auditoría: Monitoreo de llamadas a sudo en tiempo real.

El principio de no repudio exige que cada invocación de sudo quede registrada de forma inalterable y pueda ser analizada por el Centro de Operaciones de Seguridad (SOC) o enviada a un sistema SIEM (Security Information and Event Management).

La auditoría de las llamadas a sudo es un requisito indispensable para garantizar la trazabilidad y detectar patrones anómalos o intentos de abuso de privilegios.

Configuración del diario del sistema (journalctl)

Para inspeccionar en tiempo real todas las ejecuciones de sudo registradas por el sistema operativo:

journalctl -u sudo -f

O filtrar directamente en los logs de autenticación de syslog:

tail -f /var/log/secure | grep sudo

Centralización e intensificación de logs de sudo

Por defecto, sudo registra las ejecuciones en /var/log/auth.log o mediante journalctl. Es fundamental asegurar que las fallas de autenticación y los intentos de uso no autorizado queden explícitamente parametrizados en /etc/sudoers:

# Habilitar logs detallados y desviar a un archivo dedicado
Defaults logfile="/var/log/sudo.log"
Defaults log_year, long_otp_prompt
Defaults badpass_message="Autenticación fallida. Evento reportado."

Para auditar la ejecución de /usr/bin/sudo e interceptar las llamadas al sistema incluso si un atacante intenta alterar los registros de syslog, se añade la siguiente regla en /etc/audit/rules.d/audit.rules:

# Auditar la ejecución del binario sudo
-w /usr/bin/sudo -p x -k uso_de_sudo

# Auditar modificaciones en el archivo de políticas sudoers
-w /etc/sudoers -p wa -k cambios_sudoers
-w /etc/sudoers.d/ -p wa -k cambios_sudoers

Para consultar las alertas generadas por el subsistema de auditoría:

ausearch -k uso_de_sudo --raw | aureport -f -i

Auditoría a nivel de Kernel con auditd

Para evitar que un usuario manipule el archivo /var/log/sudo.log, el kernel de Linux debe monitorear la ejecución de las llamadas al sistema (syscalls) asociadas al binario /usr/bin/sudo.

Regla para /etc/audit/rules.d/sudo.rules:

# Monitorear cualquier ejecución del binario sudo
-w /usr/bin/sudo -p x -k ejecucion_sudo

# Monitorear modificaciones en el archivo de configuración sudoers
-w /etc/sudoers -p wa -k cambio_sudoers
-w /etc/sudoers.d/ -p wa -k cambio_sudoers

Integración con SIEM y alertas en tiempo real

Las llamadas interceptadas por auditd o rsyslog deben ser reenviadas mediante un agente de transporte seguro (como Filebeat o Fluentbit) bajo protocolo TLS hacia la plataforma de logs centralizada.

Las métricas críticas que deben disparar una alarma de seguridad de nivel de severidad Alto/Crítico incluyen:

• Métrica sudo_failed_attempts: Más de 3 intentos fallidos de contraseña consecutivos por parte de un usuario nominal.

• Métrica sudo_unauthorized_command: Intentos de ejecución de comandos fuera del Cmnd_Alias asignado (evento COMMAND_NOT_ALLOWED).

• Métrica sudoedit_integrity: Modificaciones no autorizadas en el directorio /etc/sudoers.d/.

6. Conclusiones

La gestión de la elevación de privilegios en sistemas operativos Linux y POSIX constituye uno de los pilares más determinantes en la arquitectura de seguridad, la resiliencia operativa y la gobernanza de TI. A lo largo de este análisis se ha demostrado que la elección entre la elevación puntual mediante sudo y la apertura de sesiones interactivas directas como root (su - o inicio de sesión nativo) no es una cuestión de preferencia individual o comodidad administrativa, sino una decisión táctica fundamentada en el análisis de riesgos, la naturaleza del entorno y el ciclo de vida de los datos.

A partir del desarrollo técnico, operativo y conceptual abordado en este trabajo, se establecen las siguientes conclusiones fundamentales:

6.a) Selección de arquitectura según requerimientos de seguridad e impacto

La conclusión principal de este estudio es que la decisión arquitectónica de emplear sudo o la cuenta de superusuario directa (su - / root) debe determinarse en función de los requerimientos específicos de seguridad, el perfil técnico del operador y el impacto potencial ante fugas, daños, pérdida de confidencialidad o bloqueos de la información del equipo:

• Servidores de producción e infraestructura crítica: El impacto de un compromiso o error operativo es catastrófico para la continuidad del negocio. En estos entornos, la arquitectura exige el uso estricto y exclusivo de sudo, deshabilitando el acceso directo a root vía SSH (PermitRootLogin no) para priorizar la trazabilidad no repudiable, la auditoría y la contención del riesgo.

• Estaciones de trabajo de escritorio administradas por expertos: En equipos de uso diario operados por ingenieros o administradores de sistemas que requieren elevar privilegios con frecuencia, la arquitectura óptima es el uso de sudo (o Polkit/pkexec). No obstante, esto exige de forma obligatoria un hardening explícito de /etc/sudoers (exigir la clave de root mediante targetpw, deshabilitar el caché con timestamp_timeout=0 y restringir binarios interactivos con sudoedit).

• Estaciones de trabajo de escritorio para usuarios finales (sin conocimientos de administración de Linux): Las distribuciones que preconfiguran un sudo permisivo de fábrica (como Ubuntu o Mint), donde la clave de inicio de sesión diaria otorga control total, representan un grave riesgo de seguridad. La arquitectura en este perfil exige prohibir el despliegue de distribuciones con sudo predeterminado permisivo, optando por distribuciones amigables de fábrica pero seguras en su arquitectura (como Mageia, Debian o PCLOS), donde el usuario opera diariamente en una cuenta estándar y recurre a la clave de root independiente vía su - (o Polkit) para tareas administrativas ocasionales.

• Computadores portátiles administrados por expertos: El riesgo dominante es la pérdida física o el robo del equipo en entornos móviles o redes no confiables. La arquitectura requiere la combinación obligatoria de cifrado completo de disco (LUKS) con sudo endurecido (timestamp_timeout=0 y targetpw) para proteger los datos en reposo y evitar el secuestro del caché de sesión en caso de sustracción con el equipo encendido.

• Computadores portátiles para usuarios finales: Ante la exposición doble de robo físico y navegación no restrictiva, la arquitectura exige cifrado completo de disco (LUKS) desde el instalador gráfico y el uso de un usuario sin privilegios en distribuciones con estricta separación de identidades de origen (como Mageia, Debian o PCLOS). La administración debe realizarse exclusivamente con la contraseña de root aislada y dedicada, prohibiendo la clave de inicio de sesión como mecanismo de elevación.

• Entornos de pruebas de penetración (pentesting) y análisis forense: En plataformas como Kali, Parrot, Cyborg Hawk o distribuciones dedicadas a auditorías de seguridad, el sistema está desprovisto de información confidencial o corporativa sensible y las herramientas (escáneres RAW, inyección de tramas, manipuladores de memoria) requieren privilegios continuos de bajo nivel. En este contexto, el impacto local de un fallo es marginal, por lo que la arquitectura opta por la operación directa como root (su -), priorizando la eficiencia operativa y eliminando la fricción de autenticación.

• Entornos Live OS (Sistemas Efímeros en Medios Removibles): En sistemas ejecutados completamente en memoria RAM desde medios USB/CD para tareas de recuperación, instalación o navegación segura en equipos no confiables, la arquitectura adopta la operación como root o sudo NOPASSWD. Dado que la memoria RAM se purga por completo al apagar el equipo y la persistencia es nula por diseño, el riesgo de persistencia de malware a largo plazo o fugas queda anulado por la volatilidad del medio.

6.b) El principio de segmentación como barrera de contención

La restricción del uso continuo de la cuenta root en entornos que procesan información crítica actúa como un mecanismo de segmentación activa del sistema de archivos y de memoria.

Esta separación formal entre la sesión del usuario común (UID ≥ 1000) y el espacio del sistema (UID 0) garantiza que el compromiso de aplicaciones cliente (navegadores web, lectores de correo electrónico o scripts ejecutados inadvertidamente) mantenga las amenazas estrictamente confinadas en el espacio personal del usuario (/home/usuario). Esta barrera evita la instalación de rootkits a nivel de kernel, el cifrado generalizado del sistema operativo por ransomware o la corrupción irrecuperable de la infraestructura global.

6.c) Trazabilidad y no repudio como requisitos de gobernanza

En la administración de infraestructura corporativa e industrial sujeta a marcos de cumplimiento normativo y estándares internacionales (ISO/IEC 27001, PCI-DSS, NIST SP 800-53), el anonimato operativo es inaceptable.

El inicio de sesión directo como root destruye la cadena de atribución individual, imposibilitando identificar quién ejecutó una acción o modificación específica. El uso disciplinado de sudo, integrado de forma nativa con los subsistemas de auditoría del sistema operativo (journald y auditd), preserva el identificador único de inicio de sesión de auditoría (auid), garantizando el no repudio, la fiscalización de comandos en tiempo real y la capacidad de análisis forense post-mortem.

6.d) La necesidad imperativa del Hardening en la delegación de permisos

Delegar privilegios a través de sudo no constituye una garantía de seguridad por sí mismo si la configuración subyacente es la que se entrega de fábrica en distribuciones orientadas a consumo masivo.

Otorgar permisos sobre binarios interactivos (GTFOBins), mantener variables de entorno peligrosas, habilitar ventanas de caché de sesión prolongadas (timestamp_timeout) o no restringir la edición de archivos mediante sudoedit neutraliza las ventajas del sistema y abre la puerta a la escalada involuntaria de privilegios. El endurecimiento (hardening) explícito de /etc/sudoers mediante la herramienta visudo es una condición técnica indispensable para que la arquitectura de delegación puntual cumpla de manera efectiva su función de protección.

En síntesis, la madurez en la ingeniería de sistemas Linux reside en la capacidad de evaluar los requerimientos de seguridad, la volatilidad de los datos y el nivel técnico del operador para seleccionar la arquitectura adecuada: restringir el privilegio al mínimo indispensable mediante el uso disciplinado o endurecido de sudo donde existan datos e infraestructura que proteger, y liberar el acceso directo como root solo en los entornos donde la volatilidad, la temporalidad y la naturaleza de la tarea así lo justifiquen.

Licencia

Superusuario o Privilegio Temporal: Cuándo y Cómo Elegir entre root y sudo en Linux está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.