Usuarios, grupos, credenciales y sesiones locales

Un usuario no es una línea de texto ni una sesión abierta

En un equipo compartido, una persona escribe un nombre, introduce una contraseña y obtiene un prompt. Desde fuera parece una operación única: «el usuario entró». Para el sistema operativo son varias transiciones distintas. Un nombre se busca en una fuente de cuentas; una credencial se verifica; una política decide si el acceso está permitido; un proceso recibe identificadores y grupos; finalmente se construye una sesión con procesos, entorno, terminal y recursos. Cada transición puede fallar o conservar un estado distinto.

Esta separación importa para analizar seguridad local. Que exista una cuenta no demuestra que una persona pueda autenticarse. Que una contraseña sea correcta no concede cualquier operación. Que un proceso se llame backup no prueba que posea la autoridad esperada. Que una terminal se cierre no demuestra que todos los procesos de la sesión hayan terminado. El capítulo estudia el modelo local de estilo Unix/Linux, declara qué parte es POSIX y qué parte es una implementación de Linux, y muestra cómo formular conclusiones limitadas.

¿Qué representa un usuario local?

Un principal es una entidad a la que una política atribuye acciones: puede ser una persona, un servicio o un proceso. Una cuenta local es el registro que relaciona un nombre legible con identificadores y atributos usados por el sistema. En Unix, el identificador de usuario (user identifier, UID) es el valor que aparece en las credenciales de un proceso y en los metadatos de archivos; el nombre es una convención de resolución. Dos nombres distintos no deberían reutilizar el mismo UID sin una razón administrativa explícita, pero la igualdad de nombres por sí sola no determina autoridad.

La base de cuentas no es necesariamente un archivo. POSIX define interfaces como getpwnam() para buscar una entrada por nombre y getpwuid() para buscarla por UID; el mecanismo subyacente puede ser local u otro servicio de nombres. En Linux, la configuración de Name Service Switch (NSS) decide el orden de fuentes como archivos locales, LDAP u otros módulos. Por eso «usuario local» debe significar aquí una cuenta que el host puede resolver y usar localmente, no necesariamente que todos sus datos estén escritos en /etc/passwd.

Una entrada sintética de passwd puede verse así:

analista:x:2104:220:Cuenta de análisis:/srv/analista:/usr/bin/bash

El formato separa nombre, campo de contraseña, UID, GID primario, descripción, directorio inicial y shell. La x no es una contraseña; normalmente indica que la información de contraseña está en otra fuente, como /etc/shadow. La línea tampoco prueba que el shell exista, que el directorio tenga los permisos correctos o que el servicio de login permita usar la cuenta. Es un dato de resolución, no una decisión completa de acceso.

El GID primario es una asociación inicial del principal con un grupo. Los grupos adicionales pueden proceder de la base de grupos y de una política de sesión. Una cuenta puede resolverse correctamente y aun así no aparecer en un grupo suplementario porque el proceso fue creado antes de cambiar la membresía, porque NSS devuelve otra fuente primero o porque la sesión no volvió a inicializar sus credenciales. Esta es una razón para observar el proceso real, no sólo editar archivos.

La cuenta aporta datos; PAM y el proceso introducen estados posteriores que deben observarse por separado.

Identidad, autenticación y autorización hacen trabajos distintos

Identidad es la respuesta a «¿qué principal representa este nombre o UID?». Autenticación es la verificación de una credencial presentada frente a una política. Autorización decide si ese principal, en ese contexto y sobre ese objeto, puede realizar una operación. Un resultado positivo en una etapa no sustituye las otras. El registro analista puede existir, una contraseña puede validarse y, aun así, la apertura de un archivo ser rechazada por su propietario, grupo, modo, ACL o una política adicional.

Una contraseña es una credencial de conocimiento, no la identidad completa ni la sesión. PAM (Pluggable Authentication Modules) permite componer fases de autenticación, cuenta, establecimiento de credenciales y apertura de sesión. La interfaz pam_setcred() describe la fase que establece o elimina credenciales antes o después de abrir una sesión; una instalación concreta puede usar contraseña, llave, tarjeta, segundo factor o un módulo que consulte un proveedor remoto. No conviene inferir el método sólo a partir de que el prompt se parezca al de otro equipo.

La autenticación también puede terminar sin crear una sesión interactiva. Un servicio puede validar una credencial para una operación puntual, y un programa de mantenimiento puede arrancar un proceso con una cuenta de servicio sin que exista una persona sentada ante una terminal. En cambio, una sesión gráfica puede usar credenciales ya verificadas por un gestor y crear muchos procesos. La pregunta profesional es qué credencial se verificó, qué proceso recibió qué atributos y cuánto tiempo siguen vigentes.

¿Dónde vive la credencial de contraseña?

En el modelo tradicional de Linux, /etc/passwd contiene datos de cuenta y /etc/shadow guarda el verificador de contraseña y atributos de caducidad. La página shadow(5) documenta que el archivo debe restringirse para preservar la seguridad de las contraseñas y que campos como el bloqueo, la edad máxima y la expiración de cuenta tienen significados distintos. No debe describirse el contenido como «la contraseña cifrada»: es un valor utilizado por un mecanismo de verificación, y la política exacta depende del formato y del módulo.

La separación de archivos reduce la exposición de los verificadores, pero no convierte al host en una frontera mágica. Un proceso con autoridad suficiente puede leer o cambiar esos archivos; una copia de seguridad puede contenerlos; un módulo NSS o PAM puede enviar la consulta a otro sistema; y un usuario puede seguir autenticado en una sesión ya abierta aunque su cuenta se bloquee después. La acción de deshabilitar una cuenta debe analizar creación de nuevos accesos, procesos existentes, credenciales en memoria, tareas programadas y canales de administración.

Conviene distinguir tres estados que suelen mezclarse:

• Cuenta bloqueada o expirada: una política impide una clase de autenticación o la entrada de la cuenta. No implica que todo proceso que ya tenía sus credenciales termine de inmediato.
• Contraseña expirada: la contraseña deja de ser aceptable o exige cambio según las reglas de la fuente de cuentas. Otro método de autenticación puede tener reglas diferentes.
• Sesión existente: procesos ya creados conservan los atributos con los que fueron iniciados hasta que una política o el kernel los modifique. Cerrar la cuenta y cerrar la sesión son operaciones distintas.

La fuente oficial passwd(5) y la de shadow(5) son referencias de formato para Linux; no autorizan a universalizar el comportamiento a macOS, BSD, Windows o un directorio corporativo. En un claim de auditoría debe constar la distribución, la versión de las herramientas, la configuración de NSS/PAM y el momento de la observación.

¿Cómo se convierten los datos de cuenta en credenciales de proceso?

Al ejecutar un programa, el kernel asocia al proceso credenciales de usuario y grupo. Linux documenta identificadores real, efectivo, guardado y, como extensión, de sistema de archivos; también documenta el GID real, efectivo, guardado, el GID de sistema de archivos y la lista de grupos suplementarios. El UID real suele conservar el origen de la ejecución; el UID efectivo participa en comprobaciones de privilegio; el UID guardado permite determinadas transiciones en programas que lo soportan. Los identificadores de sistema de archivos (fsuid y fsgid) son los que Linux usa específicamente para comprobar permisos de acceso al filesystem y normalmente siguen a los efectivos, aunque interfaces privilegiadas pueden separarlos. No son sinónimos ni deben resumirse como «el UID del usuario» sin indicar cuál. Linux credentials(7), “User and group identifiers”

Una comprobación sobre un archivo usa el contexto de credenciales del proceso y los metadatos del objeto. En Linux, el fsuid/fsgid y los grupos suplementarios participan en esa decisión; de forma simplificada, el kernel identifica si coincide el propietario, si corresponde el grupo y qué clase de modo o ACL aplica. La lista suplementaria puede hacer que una operación sea posible aunque el GID primario no coincida. Esta explicación es deliberadamente acotada: capabilities, ACL, namespaces, MAC y sistemas de archivos remotos pueden añadir reglas. El hecho de que id muestre un grupo o un UID efectivo no prueba por sí solo qué fsuid/fsgid usa el proceso ni que toda aplicación o montaje interprete la operación igual; hay que observar las credenciales del PID mediante una interfaz apropiada, por ejemplo /proc/<pid>/status en el sistema evaluado.

Un proceso hijo hereda credenciales y grupos al crearse, y execve() sustituye el programa sin borrar automáticamente la identidad del proceso. Un servicio que cambia membresías no actualiza mágicamente procesos ya iniciados. Del mismo modo, cambiar el archivo de configuración después de arrancar un daemon no cambia su UID efectivo. La evidencia correcta combina la configuración que debía aplicar con la lectura del proceso en ejecución.

El modelo de set-user-ID (setuid) introduce una transición especialmente delicada. Un ejecutable con un atributo setuid puede iniciarse con un UID efectivo distinto del UID real del invocador, según reglas del sistema de archivos y del kernel. El objetivo histórico es permitir una operación acotada que necesita autoridad adicional; el límite depende del código, de los descriptores heredados, del entorno y de cualquier ruta que ejecute entradas controladas por el invocador. «Corre como root» describe una condición de autoridad, no una conclusión sobre la corrección del programa.

En Linux moderno, las capabilities dividen parte de la autoridad tradicional del superusuario en unidades separadas. Esto puede reducir el conjunto de privilegios de un servicio, pero exige identificar las capabilities efectivas, permitidas y heredables y las reglas de la operación concreta. No es correcto concluir que un proceso sin UID 0 es inofensivo ni que uno con UID 0 tiene idéntica autoridad en todos los namespaces. Para este capítulo basta conservar el principio: el UID es una entrada del modelo de autorización, no una medición completa de poder.

En Linux, las credenciales son componentes con alcances distintos, no un único “UID del usuario”.

¿Qué aportan realmente los grupos?

Un grupo es un conjunto de principales identificado por GID que permite expresar una política colectiva. El directorio de proyectos puede pertenecer a analisis, mientras que cada archivo conserva un propietario individual. El grupo evita una lista de permisos por persona, pero introduce una dependencia: la membresía debe resolverse, transferirse a la sesión y mantenerse coherente con el ciclo de vida de la cuenta.

La distinción entre grupo primario y grupos suplementarios es operacional. El primero suele influir en el GID con el que se crean nuevos archivos; los segundos amplían la identidad de autorización del proceso. Una sesión que muestra groups=analisis puede crear un archivo con un GID distinto si el proceso o el directorio aplican otra regla. No debe confundirse el grupo de un archivo con la lista de grupos de quien intenta abrirlo.

Un error frecuente es tratar un grupo como un rol de negocio. Ser miembro de backup puede habilitar lectura sobre cierto árbol, pero no define por sí solo qué operación de respaldo es apropiada, quién la aprobó ni cuándo caduca. La política profesional especifica objeto, operación, momento y evidencia. También considera cuentas de servicio, grupos anidados o remotos y la posibilidad de que una sesión antigua conserve membresías revocadas.

Otro error es usar la edición de /etc/group como prueba de que todos los procesos perdieron acceso. La membresía que ya fue materializada en las credenciales del proceso no cambia por reescribir una línea. Un cambio requiere definir si se reinician sesiones, si se terminan procesos descendientes y cómo se verifica el efecto. El control positivo puede ser un proceso nuevo creado después de la modificación; el negativo, un proceso antiguo que se esperaba revocar, siempre dentro de una ventana autorizada.

¿Qué es una sesión local?

Una sesión es un contexto de procesos y recursos asociado a una apertura de acceso; no es sinónimo de contraseña, token ni terminal. POSIX define grupos de procesos, sesiones y terminal de control para el job control. En Linux, setsid() crea una sesión nueva sólo si el proceso invocador no es ya líder de un grupo de procesos; si lo es, falla. Cuando tiene éxito, el invocador se convierte en líder de la nueva sesión y de un nuevo grupo de procesos, inicialmente único en ambos, y la sesión comienza sin terminal de control. Esta precondición explica el fork() previo de patrones históricos de daemonización. Una sesión puede adquirir después una terminal de control y mantener un único grupo en primer plano para ella. Linux setsid(2), DESCRIPTION y NOTES

El flujo habitual puede describirse así: un servicio de login recibe una conexión; un módulo autentica y aplica restricciones; se establecen UID, GID y grupos; se prepara el entorno y el directorio inicial; se abre una sesión PAM; se inicia un proceso de shell o una aplicación; los descendientes heredan parte de ese estado. Cerrar la ventana sólo afecta a la ruta que el terminal gestionaba. Un proceso que se desprendió, un servicio que quedó bajo un supervisor o una tarea programada pueden seguir ejecutándose con credenciales y acceso propios.

La sesión sirve para razonar sobre alcance y limpieza, no para prometer aislamiento absoluto. Variables de entorno, descriptores abiertos, sockets, agentes de claves y archivos temporales pueden cruzar la frontera de un proceso a otro. La configuración de un gestor de sesión, el supervisor y la distribución determina qué se cierra al salir. Un claim como «al cerrar sesión se revocan todos los accesos» requiere pruebas específicas sobre procesos, credenciales, sockets y recursos, no sólo observar que desapareció el prompt.

Un token de aplicación puede representar una sesión de servicio, pero no es la sesión del kernel ni necesariamente el UID del proceso. Un cliente puede conservar un token en un archivo legible para el mismo usuario mientras el proceso usa una identidad local distinta. Autenticación local, credenciales de proceso y estado de aplicación deben correlacionarse sin tratarlos como una sola cosa.

Revocar futuras autenticaciones no describe automáticamente la vida de procesos ni el acceso de cada objeto.

Leer evidencia sin inventar una identidad

Para analizar un caso local, empiece por una pregunta y capture el contexto. Un conjunto sintético de observaciones podría ser:

# Bash en el host de análisis; los valores son de ejemplo, no credenciales reales.
getent passwd analista
getent group analisis
id analista
cat /proc/4242/status | sed -n 's/^\(Uid\|Gid\|Groups\):/\0/p'

getent observa la resolución mediante NSS; no demuestra que la cuenta se haya autenticado. id muestra la identidad resuelta o la del proceso invocador; no captura por sí solo un servicio que cambió de UID. /proc aporta una observación de un proceso concreto, cuya vigencia, namespace y permisos de lectura deben registrarse. La evidencia debe incluir host, versión, hora, fuente de nombres, PID, ancestro relevante y si el proceso se creó antes o después del cambio.

Una adjudicación profesional separa cuatro capas. Observación: el proceso 4242 tiene determinados UID, GID y grupos en el instante de la lectura. Inferencia: esos atributos lo habilitan o no para la comprobación que se reconstruye. Impacto posible: una ruta de archivo o socket podría quedar accesible si la configuración y el objeto coinciden. Decisión: reiniciar sesión, reducir grupo, cambiar política o aceptar la exposición, con autoridad y alcance explícitos. No llame «evidencia» a la hipótesis de que una cuenta fue comprometida ni «incidente» a una alerta de login sin contexto.

La observación de /etc/passwd tampoco basta para declarar que un login funcionará. Hay que comparar la fuente efectiva de NSS, la política PAM, la expiración de cuenta y la existencia del shell y del directorio. Para un archivo, se debe observar propietario, grupo, modo, ACL, montaje y contexto adicional si aplica. Para una sesión, se necesita el árbol de procesos, los IDs de sesión y grupos, la terminal o supervisor y los recursos que permanecen abiertos.

Límites del modelo y errores frecuentes

El capítulo no cubre la autenticación central completa, Kerberos, directorios empresariales, políticas Windows, hardware tokens ni todos los mecanismos de un escritorio. Se mencionan para marcar la frontera: un host puede consultar una identidad remota y materializarla en credenciales locales, pero los atributos, fallos y revocación dependen de esa integración. Tampoco se deriva una conclusión sobre user namespaces sólo porque aparezca UID 0: el significado del identificador depende del namespace y del objeto observado.

Los errores más costosos son de transición. Confundir nombre con UID hace que un registro se atribuya a la cuenta equivocada. Confundir autenticación con autorización lleva a otorgar permisos excesivos después de validar una contraseña. Confundir grupo configurado con grupo efectivo deja accesos antiguos o rompe un servicio legítimo. Confundir terminal con sesión omite procesos huérfanos. Confundir UID efectivo con intención permite leer «root» como «seguro» o «malicioso» sin analizar el código y la operación.

También es un error tratar la revocación como una edición de datos. La acción debe declarar qué estado se revoca: futuras autenticaciones, nuevos procesos, sesión actual, credenciales de un daemon, tokens de aplicación o acceso a un objeto. Cada estado tiene una prueba distinta. Una corrección puede mitigar la condición sin remediar la causa; por ejemplo, terminar una sesión vieja reduce exposición pero no explica por qué la membresía no se actualizó ni evita que reaparezca.

Uso profesional: formular un claim local acotado

Un claim útil puede decir: «En el host H, con la configuración NSS/PAM V observada el día D, una sesión nueva para la cuenta sintética analista materializa UID 2104, GID 220 y los grupos declarados, y el proceso de shell no puede leer el archivo de prueba fuera de esos permisos». El claim identifica fuente, versión, tiempo, proceso, objeto y operación. No autoriza afirmar que todos los servicios, sesiones previas, montajes remotos o cuentas equivalentes se comportan igual.

La evidencia correspondiente combina configuración de fuentes, entrada de cuenta, política de autenticación, credenciales del proceso, metadatos del archivo y una prueba positiva y negativa. Si la cuenta se deshabilita, el claim de revocación debe añadir qué sesiones y procesos estaban vivos, qué se terminó y qué acceso se comprobó después. Si la identidad proviene de un directorio remoto, el alcance debe incluir disponibilidad, caché y reglas de mapeo sin fingir que es una cuenta puramente local.

Este estilo permite elegir controles con un objetivo claro: usar grupos para una colección estable de objetos, separar cuentas de servicio de personas, limitar capabilities, hacer explícita la pertenencia temporal y supervisar la vida de procesos. Ningún control hereda propiedades que no se midieron. La decisión profesional relaciona autoridad requerida, operación, condición, evidencia y límite.

Síntesis

El modelo local encadena resolución de identidad, autenticación, establecimiento de credenciales, autorización y sesión. Un usuario es un principal interpretado por una fuente; un UID o GID es un identificador operacional; un grupo es una entrada de política; una contraseña es sólo un tipo de credencial; una sesión reúne procesos y recursos durante un intervalo. El kernel aplica parte de estas reglas al proceso, pero la configuración de NSS, PAM, el sistema de archivos, el supervisor y la aplicación completan la historia.

La pregunta correcta no es «¿qué usuario inició sesión?», sino «¿qué fuente resolvió qué principal, qué credencial fue verificada, qué atributos recibió el proceso, qué sesión sigue viva y qué operación permite cada frontera?». Con esa pregunta se puede investigar una revocación, un grupo inesperado o un servicio privilegiado sin atribuir a un nombre una autoridad que la evidencia no demuestra.

Comprobación de comprensión

1. ¿Por qué una entrada válida de /etc/passwd no prueba que una cuenta pueda autenticarse ni abrir un archivo? Respuesta: resuelve una cuenta; aún faltan política/credencial PAM y autorización sobre el objeto. Límite: no atribuir la causa sin observar la fuente efectiva y el servicio.
2. Compara identidad, autenticación y autorización en una operación local concreta. Respuesta: identidad resuelve el principal; autenticación verifica una credencial; autorización decide la operación con las credenciales y metadatos vigentes. Límite: una contraseña válida no prueba permiso.
3. ¿Qué diferencia práctica hay entre UID real, UID efectivo y grupos suplementarios? Respuesta: el real conserva el origen, el efectivo participa en comprobaciones y los suplementarios amplían la pertenencia del proceso. Límite: en Linux también importan fsuid/fsgid, capabilities y el objeto.
4. ¿Por qué editar /etc/group no revoca automáticamente el acceso de todo proceso existente? Respuesta: los grupos se materializan en credenciales al crear o cambiar el proceso. Límite: el acceso podría proceder del propietario, una ACL, otro montaje o una cuenta distinta.
5. Distingue cuenta bloqueada, contraseña expirada y sesión ya abierta. Respuesta: son estados de política y ciclo de vida diferentes; bloquear futuras autenticaciones no termina necesariamente procesos existentes. Límite: el efecto depende de la política, el método y el supervisor observados.
6. ¿Qué parte del flujo construye una sesión y qué puede permanecer después de cerrar una terminal? Respuesta: el servicio y PAM abren sesión, establecen credenciales y crean procesos; un supervisor, proceso desprendido o recurso abierto puede sobrevivir. Límite: cerrar una ventana no mide por sí solo toda la sesión.
7. ¿Qué observaciones necesitas para sostener que un servicio corre con la autoridad mínima prevista? Respuesta: host/versión, PID y ancestro, UIDs/GIDs, grupos, fsuid/fsgid, capabilities, objeto y operación. Límite: un UID no resume toda autoridad ni demuestra intención.
8. Formula un claim local que incluya host, versión, fuente de identidad, proceso, objeto, operación y límites. Respuesta: declarar esos campos, momento, controles positivo/negativo y resultado. Límite: no extenderlo a sesiones antiguas, namespaces, montajes o cambios no medidos.

Problema de transferencia

Un equipo revoca a analista del grupo archivos, edita su cuenta para bloquear nuevas contraseñas y observa que un proceso iniciado horas antes todavía puede leer un archivo del proyecto. Reconstruye hipótesis alternativas sin llamar incidente al hecho inicial. Separa configuración, credenciales efectivas, sesión, objeto y operación; especifica un control positivo y uno negativo; y redacta qué conclusión quedaría fuera de alcance si no se conoce la fuente NSS ni el supervisor que inició el proceso.

Fuentes principales

• The Open Group. POSIX.1-2017: getpwnam() y sesiones y grupos de procesos.
• Linux man-pages. credentials(7), passwd(5), group(5), shadow(5), pam(8) y setsid(2).
• Linux-PAM. pam_setcred(3) y pam_open_session(3).