Los indicadores de derechos de acceso de Unix y Linux setuid y setgid (abreviatura de set user identity y set group identity ) [1] permiten a los usuarios ejecutar un ejecutable con los permisos del sistema de archivos del propietario o grupo del ejecutable respectivamente y cambiar el comportamiento en los directorios. A menudo se utilizan para permitir que los usuarios de un sistema informático ejecuten programas con privilegios elevados temporalmente para realizar una tarea específica. Si bien los privilegios de identificación de usuario o identificación de grupo asumidos no siempre son elevados, como mínimo son específicos.
Las banderas setuidy setgidson necesarias para tareas que requieren privilegios diferentes a los que normalmente se le otorgan al usuario, como la capacidad de alterar archivos del sistema o bases de datos para cambiar su contraseña de inicio de sesión. [2] Sin embargo, algunas de las tareas que requieren privilegios adicionales pueden no ser obvias de inmediato, como el pingcomando, que debe enviar y escuchar paquetes de control en una interfaz de red.
Los bits setuidy setgidnormalmente se representan como los valores 4 para setuidy 2 para setgiden el dígito octal de orden superior del modo de archivo. Por ejemplo, 6711tiene los bits setuidy setgid( 4 + 2 = 6 ) establecidos, y también el archivo de lectura/escritura/ejecución para el propietario (7), y ejecutable por el grupo (primero 1) y otros (segundo 1). La mayoría de las implementaciones tienen una representación simbólica de estos bits; en el ejemplo anterior, esto podría ser u=rwx,go=x,ug+s.
Normalmente, chmodno tiene un modo recursivo restringido a directorios, por lo que la modificación de un árbol de directorios existente debe hacerse manualmente, con un comando como .find /path/to/directory -type d -exec chmod g+s '{}' '\'
Los indicadores setuidy setgidtienen efectos diferentes, dependiendo de si se aplican a un archivo, a un directorio o a un archivo ejecutable binario o no binario. Los indicadores setuidy setgidtienen efecto solo en archivos ejecutables binarios y no en scripts (por ejemplo, Bash, Perl, Python). [3]
Cuando se establecen los atributos setuido en un archivo ejecutable , entonces cualquier usuario capaz de ejecutar el archivo ejecutará automáticamente el archivo con los privilegios del propietario del archivo (comúnmente root ) y/o el grupo del archivo, dependiendo de los indicadores establecidos. [2] Esto permite al diseñador del sistema permitir que se ejecuten programas confiables que de otra manera un usuario no podría ejecutar. Estos pueden no ser siempre obvios. Por ejemplo, el comando ping puede necesitar acceso a privilegios de red a los que un usuario normal no puede acceder; por lo tanto, se le puede dar el indicador setuid para garantizar que un usuario que necesita hacer ping a otro sistema pueda hacerlo, incluso si su cuenta no tiene el privilegio requerido para enviar paquetes.setgid
Por motivos de seguridad, el sistema generalmente prohíbe al usuario que realiza la invocación alterar el nuevo proceso de cualquier forma, como por ejemplo mediante el uso ptraceo LD_LIBRARY_PATHel envío de señales para explotar el privilegio obtenido, aunque las señales desde la terminal seguirán siendo aceptadas.
Si bien la setuidcaracterística es muy útil en muchos casos, su uso indebido puede representar un riesgo de seguridad [2] si el setuidatributo se asigna a programas ejecutables que no están diseñados cuidadosamente. Debido a posibles problemas de seguridad, [4] muchos sistemas operativos ignoran el atributo cuando se aplica a scripts de shellsetuid ejecutables . [ cita requerida ]
La presencia de setuidejecutables explica por qué la chrootllamada al sistema no está disponible para usuarios que no sean root en Unix. Consulte las limitaciones dechroot para obtener más detalles.
Al establecer el setgidpermiso en un directorio, los archivos y subdirectorios creados en él heredan su grupo de propiedad, en lugar de heredar el grupo principal del proceso de creación del archivo. Los subdirectorios creados también heredan el setgidbit. La política solo se aplica durante la creación y, por lo tanto, solo de manera prospectiva. Los directorios y archivos existentes cuando setgidse aplica el bit no se ven afectados, al igual que los directorios y archivos que se mueven al directorio en el que se establece el bit.
De esta forma, se concede la capacidad de trabajar con archivos entre un grupo de usuarios sin establecer permisos explícitos, pero limitado por la expectativa del modelo de seguridad de que los permisos de los archivos existentes no cambien implícitamente.
El setuidpermiso establecido en un directorio se ignora en la mayoría de los sistemas UNIX y Linux . [5] [ cita requerida ] Sin embargo, FreeBSD se puede configurar para interpretar setuidde manera similar a setgid, en cuyo caso obliga a que todos los archivos y subdirectorios creados en un directorio sean propiedad del propietario de ese directorio, una forma simple de herencia. [6] Esto generalmente no es necesario en la mayoría de los sistemas derivados de BSD , ya que por defecto los directorios se tratan como si su setgidbit siempre estuviera establecido, independientemente del valor real. Como se indica en open(2), "Cuando se crea un nuevo archivo, se le asigna el grupo del directorio que lo contiene". [7]
Los permisos de un archivo se pueden verificar en forma octal y/o alfabética con la herramienta de línea de comandosstat
[ torvalds ~ ] $ stat -c "%a %A" ~/prueba/ 1770 drwxrwx--T 4701 en un archivo ejecutable propiedad de 'root' y el grupo 'root'
Un usuario llamado 'thompson' intenta ejecutar el archivo. El permiso de ejecución para todos los usuarios está configurado (el '1') para que 'thompson' pueda ejecutar el archivo. El propietario del archivo es 'root' y el permiso SUID está configurado (el '4'), por lo que el archivo se ejecuta como 'root'.
La razón por la que un ejecutable se ejecuta como 'root' es para poder modificar archivos específicos que el usuario normalmente no podría modificar, sin darle al usuario acceso completo a la raíz.
Un uso predeterminado de esto se puede ver con el /usr/bin/passwdarchivo binario /usr/bin/passwdque necesita modificarse /etc/passwdy /etc/shadowque almacena información de cuenta y hashes de contraseñas para todos los usuarios, y estos solo pueden ser modificados por el usuario 'root'.
[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd 4701 raíz: raíz /usr/bin/passwd [ thompson ~ ] $ passwd passwd: Cambiar la contraseña de thompsonEl propietario del proceso no es el usuario que ejecuta el archivo ejecutable, sino el propietario del archivo ejecutable.
2770 en un directorio llamado 'music' propiedad del usuario 'root' y del grupo 'engineers'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero secundariamente al grupo 'engineers' crea un directorio llamado 'electronic' dentro del directorio llamado 'music'. La propiedad del grupo del nuevo directorio llamado 'electronic' hereda a 'engineers'. Lo mismo ocurre cuando se crea un nuevo archivo llamado 'imagine.txt'
Sin SGID, el grupo propietario del nuevo directorio/archivo habría sido 'torvalds', ya que ese es el grupo principal del usuario 'torvalds'.
[ torvalds ~ ] $ grupos torvalds torvalds : ingenieros de torvalds[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./musica/ 2770 root:ingenieros ./musica/ [ torvalds ~ ] $ mkdir ./musica/electronica[ torvalds ~ ] $ stat -c "%U:%G %n" ./música/electrónica/ torvalds:ingenieros ./música/electrónica/ [ torvalds ~ ] $ echo 'NUEVO ARCHIVO' > ./music/imagine.txt [ torvalds ~ ] $ stat -c "%U:%G %n" ./musica/imagine.txt torvalds:ingenieros ./musica/imagine.txt [ torvalds ~ ] $ toque ~/prueba[ torvalds ~ ] $ stat -c "%U:%G %n" ~/prueba torvalds:torvalds ~/prueba 1770 en un directorio llamado 'videojuegos' propiedad del usuario 'torvalds' y el grupo 'ingenieros'.
Un usuario llamado 'torvalds' crea un archivo llamado 'tekken' en el directorio 'videogames'. Un usuario llamado 'wozniak', que también forma parte del grupo 'engineers', intenta eliminar el archivo llamado 'tekken' pero no puede, ya que no es el propietario.
Sin el sticky bit, 'wozniak' podría haber eliminado el archivo, porque el directorio llamado 'videogames' permite la lectura y escritura por parte de 'engineers'. Se puede ver un uso predeterminado de esto en la /tmpcarpeta.
[ torvalds /home/shared/ ] $ grupos torvalds torvalds : ingenieros de torvalds[ torvalds /inicio/compartido/ ] $ stat -c "%a %U:%G %n" ./videojuegos/ 1770 torvalds:ingenieros ./videojuegos/ [ torvalds /home/shared/ ] $ echo 'NUEVO ARCHIVO' > videojuegos/tekken [ torvalds /home/shared/ ] $ su - wozniak Contraseña:[ wozniak ~/ ] $ grupos wozniak wozniak : ingenieros de wozniak[ wozniak ~/ ] $ cd /inicio/compartido/videojuegos[ wozniak /home/shared/videogames/ ] $ rm tekken rm: no se puede eliminar 'tekken': Operación no permitida3171 en un directorio llamado 'blog' propiedad del grupo 'ingenieros' y del usuario 'root'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero secundariamente al grupo 'engineers' crea un archivo o directorio llamado 'thoughts' dentro del directorio 'blog'. Un usuario llamado 'wozniak' que también pertenece al grupo 'engineers' no puede eliminar, renombrar o mover el archivo o directorio llamado 'thoughts', porque no es el propietario y el bit de fijación está activado. Sin embargo, si 'thoughts' es un archivo, entonces 'wozniak' puede editarlo.
Sticky bit tiene la decisión final. Si no se hubieran configurado Sticky bit y SGID, el usuario 'wozniak' podría renombrar, mover o eliminar el archivo llamado 'thoughts' porque el directorio llamado 'blog' permite la lectura y escritura por grupo, y wozniak pertenece al grupo, y la máscara de usuario predeterminada 0002 permite que los nuevos archivos sean editados por grupo. Sticky bit y SGID podrían combinarse con algo como una máscara de usuario de solo lectura o un atributo de solo anexar.
[ torvalds /home/shared/ ] $ grupos torvalds torvalds : ingenieros de torvalds[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./blog/ 3171 root:ingenieros ./blog/ [ torvalds /home/shared/ ] $ echo 'NUEVO ARCHIVO' > ./blog/thoughts [ torvalds /home/shared/ ] $ su - wozniak Contraseña:[ wozniak ~/ ] $ cd /inicio/blog/compartido[ wozniak /home/shared/blog/ ] $ grupos wozniak wozniak : ingenieros de wozniak[ wozniak /home/shared/blog/ ] $ stat -c "%a %U:%G %n" ./pensamientos 664 torvalds:ingenieros ./pensamientos [ wozniak /home/shared/blog/ ] $ rm thoughts rm: no se puede eliminar 'pensamientos': Operación no permitida[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/ mv: no se puede mover 'thoughts' a '/home/wozniak/thoughts': Operación no permitida[ wozniak /home/shared/blog/ ] $ mv pensamientos reflexionando mv: no se puede mover 'pensamientos' a 'reflexionando': Operación no permitida[ wozniak /home/shared/blog/ ] $ echo '¡REESCRIBIR!' > pensamientos [ wozniak /home/shared/blog/ ] $ pensamientos de gato ¡REESCRIBE!Los desarrolladores diseñan e implementan programas que utilizan este bit en los ejecutables con cuidado para evitar vulnerabilidades de seguridad, como desbordamientos de búfer e inyección de rutas. Los ataques de desbordamiento de búfer exitosos en aplicaciones vulnerables permiten al atacante ejecutar código arbitrario bajo los derechos del proceso explotado. En el caso de que un proceso vulnerable utilice el setuidbit para ejecutarse como root, el código se ejecutará con privilegios de root, lo que en efecto le otorga al atacante acceso de root al sistema en el que se ejecuta el proceso vulnerable.
De particular importancia en el caso de un setuidproceso es el entorno del proceso. Si el entorno no está debidamente saneado por un proceso privilegiado, su comportamiento puede ser modificado por el proceso no privilegiado que lo inició. [8] Por ejemplo, GNU libc fue vulnerable en un momento a un exploit que utilizaba setuiduna variable de entorno que permitía ejecutar código desde bibliotecas compartidas no confiables . [9]
El setuidbit fue inventado por Dennis Ritchie [10] e incluido en su. [10] Su empleador, entonces Bell Telephone Laboratories , solicitó una patente en 1972; la patente fue concedida en 1979 como patente número US 4135240 "Protección del contenido de archivos de datos". La patente fue posteriormente puesta en el dominio público . [11]