Usuarios, grupos y quién puede qué

Un usuario de Linux hereda permisos de cada grupo al que pertenece. Mete una cuenta en un grupo de administración y, a partir de ahí, puede lo que ese grupo puede, aunque su trabajo no lo pida. Por eso leer la pertenencia a grupos es el primer sitio donde mirar: ahí se ve si alguien tiene de más. En Salitre, el servidor tiene cuentas repartidas en grupos, y revisar cada una es revisar qué puede de verdad.

Los permisos no viven solo en la cuenta; viven en los grupos que la cuenta arrastra. Mirar el usuario sin mirar sus grupos es ver media foto.

El error más común no es técnico: es una cuenta en un grupo que no necesitaba, metida «para que algo funcionara» y que se quedó ahí. Una cuenta de servicio que solo sirve la web no tiene por qué estar en el grupo que permite actuar como administrador. Para quien administra es una limpieza pendiente; para quien ataca, el premio: si cae esa cuenta, hereda el poder del grupo. En Salitre hay justo un caso así.

El privilegio mínimo —cada cuenta con lo justo— es fácil de romper y difícil de sostener, porque añadir permisos arregla rápido y quitarlos no urge nunca.

Entender grupos no es solo higiene: es la base de media escalada de privilegios. Quien entra con una cuenta limitada busca exactamente esto — una pertenencia de más que lo lleve de usuario normal a control. Revisar los grupos desde el lado del defensor es cerrar esa puerta antes de que nadie la use. En Salitre, la cuenta del servicio web en el grupo de administración es el camino que un atacante que cayera en la web intentaría primero.

Leer grupos bien es, a la vez, defender (quitar lo que sobra) y entender cómo ataca el otro (buscar lo que sobra). Es el mismo dato visto desde las dos sillas.

El grupo de más no se adivina: se encuentra leyendo la pertenencia de cada cuenta. Abre el laboratorio, revisa las cuentas y sus grupos en el servidor de Salitre y baja hasta el código de sala al pie.