Explicación de los permisos y privilegios de Linux: grupos, sudo y control del sistema

Permisos de Linux explicados acceso a archivospero lo hacen No explicar Permisos del sistema. Muchos usuarios aprenden chmod Y se detiene allí, lo que puede causar confusión cuando los archivos parecen correctos pero aún fallan cosas como el reinicio o el control del servicio.

Esta guía explica Permisos y privilegios de Linuxcómo encajan los grupos y por qué el Linux moderno maneja el control del sistema de manera diferente a lo que podría pensar.

Modelo de permisos clásico de Unix

Cada archivo en Linux tiene tres tipos de propiedad:

• Propietario (usuario específico)
• Grupo (una colección de usuarios)
• Otros (todos los demás usuarios del sistema)

Cada identidad puede tener tres tipos de acceso:

• leer(r) – Ver el contenido del archivo
• escribir(w) – Modificar archivos
• ejecutar(x) – Ejecute el archivo como un programa.

Puede ver estos permisos de las siguientes maneras:

ls -l /usr/bin/sudo

El resultado es el siguiente:

-rwsr-xr-x 1 root root 281624 Jun 24  2025 /usr/bin/sudo

Desglosarlo:

• -rwsr-xr-x – Bits de permiso (más sobre esto más adelante)
• root root – El propietario es root y el grupo es root.
• El propietario puede leer, escribir y ejecutar
• Este grupo puede leer y ejecutar
• Todos los demás pueden leer y ejecutar

Este modelo controla quién puede abrir, modificar o ejecutar archivos. Es simple, básico y sigue siendo importante para proteger datos y programas. Este es el núcleo Permisos de archivos y directorios de Linux.

Por qué los grupos de Linux son importantes para los permisos

Los grupos permiten compartir de forma controlada sin tener que otorgar acceso a todos ni administrar los permisos de cada usuario.

Linux utiliza grupos para otorgar acceso a hardware y recursos:

• vocal – Equipos de sonido y hardware de audio.
• video – GPU y dispositivos gráficos
• desarrollador de enchufes – Dispositivos USB y medios extraíbles
• máquina virtual de biblioteca / gvm – máquina virtual
• disco – Acceso directo al disco

He aquí un ejemplo práctico. Revisa tu equipo de vídeo:

ls -l /dev/dri/card1

Puedes ver:

crw-rw----+ 1 root video 226, 1 Dec 30 18:00 /dev/dri/card1

El dispositivo es propiedad de root y video grupo. cualquiera en video Los grupos pueden acceder a la GPU incluso si no son root.

Para agregar un usuario a un grupo solemos hacer esto:

sudo usermod -a -G video username

El usuario ahora puede utilizar la GPU. Elimínelos del grupo y el acceso se detendrá inmediatamente (después de que cierren sesión y vuelvan a iniciarla).

Los grupos escalan mejor que las reglas por usuario y siguen siendo el núcleo de la seguridad de Linux. Proporcionan un control fino sin ser demasiado complejos.

Cómo delegar permisos en sistemas Unix tradicionales

Los sistemas Unix más antiguos utilizaban la propiedad de archivos y grupos para obtener permisos del sistema, no solo acceso a archivos.

Los patrones comunes incluyen:

• Grupos especiales como operator o shutdown
• Binarios del sistema (p. ej. /sbin/halt) son propiedad de estos grupos
• este valor establecido o establecer gid Bit permite a los miembros del grupo ejecutar con privilegios elevados

Por ejemplo, shutdown Los archivos binarios pueden pertenecer a operator Grupos con permisos especiales. Los miembros de este grupo pueden apagar la máquina porque pueden ejecutar archivos binarios con privilegios elevados.

La confianza es amplia y clara. Si confías en un grupo, puedes darle poder mediante la propiedad de archivos y bits de permisos especiales. Este método funciona bien en servidores compartidos y terminales multiusuario.

Cómo controla Linux moderno las operaciones privilegiadas

El Linux moderno ya no depende principalmente de la propiedad de los archivos para el control del sistema. En cambio, las operaciones privilegiadas pasan a través de una capa de autorización basada en políticas.

cuando corres shutdown o systemctl restartLinux no verifica primero los permisos de los archivos. Comprueba si estás permitido. políticageneralmente aplicado por:

• sistema – sistema de inicio y administrador de servicios
• polkit (anteriormente PolicyKit): marco de autorización para políticas de todo el sistema
• autobús D – Bus de mensajes que media en las solicitudes del sistema.

Esto es lo que realmente sucede cuando intentas reiniciar:

systemctl reboot

1. Tus comandos llegan a systemd a través de D-Bus
2. Polkit intercepta solicitudes de autorización
3. Reglas de inspección de polkit /usr/share/polkit-1/actions/ y /etc/polkit-1/rules.d/
4. Evalúa si está permitido en función de los siguientes factores:
   • Ya sea que estés en la consola física (local o remota)
   • Su ID de usuario y membresía de grupo
   • estado de sesión activa
   • Reglas políticas específicas

Por ejemplo, archivos de políticas /usr/share/polkit-1/actions/org.freedesktop.login1.policy Incluir:

  
    auth_admin
    auth_admin
    yes
  

Esto dice:

• usuario remoto (allow_any) debe autenticarse como administrador
• Las sesiones inactivas deben autenticarse como administrador.
• Las sesiones locales activas se pueden reiniciar sin autenticación

Los usuarios de la consola local pueden reiniciar sin sudo, mientras que los usuarios remotos de SSH normalmente requieren permisos explícitos. Este comportamiento es consistente en todas las distribuciones modernas de Linux basadas en systemd, como Ubuntu, Fedora, Arch y Debian.

Permisos y privilegios de Linux: diferencias clave

Los permisos controlan el acceso a archivos. Permisos del sistema de control de permisos.

Esta distinción explica por qué los permisos de archivo correctos no siempre otorgan control. Es posible que tenga permisos de ejecución. /usr/sbin/rebootpero eso no significa que puedas reiniciar el sistema sin los permisos adecuados.

Permisos y privilegios confusos pueden provocar errores de seguridad y frustración cuando las cosas no funcionan como se esperaba.

El papel de sudo y grupos de ruedas.

este wheel grupo (en sistemas basados ​​en Red Hat) o sudo El grupo (en sistemas basados ​​en Debian) suele ser confuso. Estos grupos no son poderosos en sí mismos; son importantes porque La política del sistema confía en ellos..

Cuando corres:

sudo systemctl restart apache2

verificación de linux /etc/sudoers (y los archivos en /etc/sudoers.d/). Las configuraciones típicas incluyen:

%sudo   ALL=(ALL:ALL) ALL

O en un sistema Red Hat:

%wheel  ALL=(ALL)       ALL

Esta línea significa: » sudo (o wheel) el grupo puede ejecutar cualquier comando como cualquier usuario en cualquier host. «

La pertenencia a un grupo es sólo una señal. La configuración de sudoers otorga poderes reales. Puedes comprobar lo que puedes hacer:

sudo -l

Esto puede generar:

User senthil may run the following commands on debian:
    (ALL : ALL) ALL

es por eso sudo y permisos es una distinción importante. Sudo otorga permisos configurando políticas en lugar de permisos de archivos.

Por qué algunos grupos tienen mayor riesgo

Algunos grupos de Linux otorgan acceso tan profundo que la membresía proporciona efectivamente funcionalidad de nivel raíz.

Grupos clave para entender

estibador – Los miembros pueden iniciar el contenedor, montar el sistema de archivos del host e ir a la raíz:

docker run -v /:/host -it ubuntu chroot /host

Esto monta todo el sistema de archivos del host y le proporciona un shell raíz.

disco – Los miembros pueden leer y escribir en dispositivos de disco sin formato:

dd if=/dev/sda of=/tmp/disk.img

Esto omite todos los permisos de archivos y puede extraer cualquier dato del disco.

sudo / rueda – Los miembros pueden convertirse en root (como se mencionó anteriormente)

máquina virtual de biblioteca / gvm – Los miembros pueden crear máquinas virtuales que accedan a los recursos del host.

largo xd – Similar a Docker, puede explotarse para escalar privilegios.

administrador – Puede leer la mayoría de los archivos de registro, exponiendo potencialmente información confidencial

Agregar usuarios a estos grupos sin comprender el impacto es peligroso. La membresía en un grupo es una decisión de seguridad, no sólo una característica de conveniencia.

Escenario práctico: diagnóstico de problemas de permisos y privilegios

Resolvamos un problema común:

Condición: desea reiniciar el servidor web Apache.

$ systemctl restart apache2
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to restart 'apache2.service'.

diagnóstico:

1. Verifique los permisos del archivo:

$ which systemctl
/usr/bin/systemctl

$ ls -l /usr/bin/systemctl
-rwxr-xr-x 1 root root 1353368 Jun 26 2025 /usr/bin/systemctl

puedes ejecutar systemctl (El bit x está configurado para todos).

Comprueba si estás en el grupo sudo:

$ groups
senthil adm cdrom dip plugdev

no estás aquí sudo grupo.

Verifique los permisos de sudo:

$ sudo -l
[sudo] password for senthil:
Sorry, user senthil may not run sudo on debian.

No tienes permisos de sudo.

solución: El problema no está en los permisos del archivo, puedes ejecutar el binario. El problema es el privilegio. Necesitas:

• ser agregado a sudo grupo: sudo usermod -a -G sudo senthil
• Obtenga permisos sudo específicos para systemctl /etc/sudoers.d/
• Usando una sesión privilegiada o en la consola local (según la política de polkit)

Esto ilustra por qué es importante comprender tanto los permisos como los privilegios.

Preguntas frecuentes sobre permisos y privilegios de Linux

P: ¿Se puede conceder acceso de root a los grupos de Linux?

Respuesta: No, el grupo en sí no puede otorgar acceso de root. Solo importan si las herramientas de autorización como sudo o la política del sistema confían en ellos. grupo wheel No hay fuerza interior; es poderosa porque /etc/sudoers Generalmente confía en ello.

P: ¿Sudo es un permiso o un privilegio?

R: Es un honor. Sudo otorga permisos a través de la configuración de políticas, no permisos de archivos. Incluso si de alguna manera puedes cambiar los permisos /usr/bin/sudono le otorgará acceso sudo.

Pregunta: ¿Por qué algunos usuarios pueden cerrar Linux sin sudo?

Respuesta: Porque la política de polkit lo permite según el estado de la sesión. Los usuarios de la consola local con sesiones activas normalmente tienen autorización automática para reiniciar o apagar, mientras que los usuarios SSH remotos no la tienen. Esto no está controlado por la propiedad. shutdown Binario.

P: ¿Cuál es la diferencia entre setuid y sudo?

Respuesta: Ambos aumentan los privilegios, pero son diferentes:

– valor establecido Es un bit de permiso de archivo que permite que un programa se ejecute como su propietario (normalmente root). Está integrado en el sistema de archivos.
– sudo Es un programa que examina archivos de políticas para decidir si otorga permisos. Es más flexible y auditable.

Los sistemas modernos prefieren sudo porque es configurable, grabable y no requiere permisos de archivo especiales.

P: ¿Cómo puedo ver en qué grupo estoy?

Respuesta: usar groups comando para ver su grupo actual, o id Para más detalles:

groups
id

Tenga en cuenta que los cambios de grupo solo tendrán efecto después de cerrar sesión y volver a iniciarla.

Puntos principales

Lo que necesitas recordar:

1. permisos de archivos (rwx, chmod) Controlar el acceso a archivos, es decir, quién puede leer, escribir o ejecutar archivos
2. privilegio (sudo, polkit) Controlar los permisos del sistema, es decir, quién puede realizar operaciones administrativas.
3. Uso moderno de Linux Autorización basada en políticasno solo la propiedad del archivo
4. algunos grupos como docker y disk es un acceso root válido
5. Ser capaz de ejecutar un binario del sistema no significa que puedas usar su funcionalidad.
6. Al solucionar problemas, pregunte: «¿Se trata de un problema de permisos (acceso a archivos) o de privilegios (permisos del sistema)?»

Obtenga más información:

La filosofía Unix todavía se mantiene

Unix no ha abandonado sus principios de comportamiento predecible, autorización clara y confianza mínima. Lo que ha cambiado son los mecanismos utilizados para implementar estos principios.

La propiedad de los archivos y los grupos aún protegen los datos. La autorización basada en políticas ahora protege la energía del sistema. Comprender ambos le permitirá administrar con confianza sus sistemas Linux, diagnosticar problemas correctamente y tomar decisiones de seguridad informadas.