Los indicadores de derechos de acceso de Unix y Linux setuid y setgid (abreviatura de establecer identidad de usuario y establecer identidad de grupo ) [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 a los usuarios de un sistema informático ejecutar 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 proporcionados 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 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 for setuidy 2 for setgiden el dígito octal de orden superior del modo de archivo. Por ejemplo, 6711tiene configurados los bits setuidy ( 4 + 2 = 6 ), y también el archivo de lectura/escritura/ejecutable 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 .setgidu=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 realizarse manualmente, con un comando como .find /path/to/directory -type d -exec chmod g+s '{}' '\'
Los indicadores setuidy setgidtienen diferentes efectos, 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 sólo en archivos ejecutables binarios y no en scripts (por ejemplo, Bash, Perl, Python). [3]
Cuando los atributos setuido setgidse configuran en un archivo ejecutable , cualquier usuario capaz de ejecutar el archivo lo ejecutará automáticamente con los privilegios del propietario del archivo (comúnmente root ) y/o del grupo del archivo, dependiendo de las banderas configuradas. [2] Esto permite al diseñador del sistema permitir que se ejecuten programas confiables que de otra manera un usuario no podría ejecutar. Es posible que estos no siempre sean 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 asignar 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.
Por motivos de seguridad, el sistema generalmente prohíbe al usuario que invoca alterar el nuevo proceso de cualquier manera, como usar ptraceo LD_LIBRARY_PATHenviarle señales, para explotar el privilegio elevado, aunque las señales del terminal aún serán aceptadas.
Si bien la setuidcaracterística es muy útil en muchos casos, su uso inadecuado puede representar un riesgo de seguridad [2] si el setuidatributo se asigna a programas ejecutables que no están cuidadosamente diseñados. Debido a posibles problemas de seguridad, [4] muchos sistemas operativos ignoran el setuidatributo cuando se aplica a scripts de shell ejecutables . [ cita necesaria ]
La presencia de setuidejecutables explica por qué la chrootllamada al sistema no está disponible para usuarios no root en Unix. Consulte las limitaciones dechroot para obtener más detalles.
Establecer el setgidpermiso en un directorio hace que los archivos y subdirectorios creados en él hereden la propiedad de su grupo, en lugar del grupo principal del proceso de creación de archivos. Los subdirectorios creados también heredan el setgidbit. La política sólo se aplica durante la creación y, por tanto, sólo de forma prospectiva. Los directorios y archivos existentes cuando setgidse aplica el bit no se ven afectados, al igual que los directorios y archivos movidos al directorio en el que se establece el bit.
Por lo tanto, se otorga la capacidad de trabajar con archivos entre un grupo de usuarios sin establecer permisos explícitamente, pero limitado por la expectativa del modelo de seguridad de que los permisos de los archivos existentes no cambian implícitamente.
El setuidpermiso establecido en un directorio se ignora en la mayoría de los sistemas UNIX y Linux . [5] [ cita necesaria ] Sin embargo , FreeBSD se puede configurar para interpretar setuidde una 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 estuviera siempre establecido, independientemente del valor real. Como se indica en open(2), "Cuando se crea un nuevo archivo, se le proporciona 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 comandostat
[ torvalds ~ ] $ stat -c "%a %A" ~/test/ 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 ejecutable 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 ejecutaría como 'root' es para que pueda modificar archivos específicos que el usuario normalmente no tendría permitido, sin darle acceso completo a la raíz.
Se puede ver un uso predeterminado de esto con el /usr/bin/passwdarchivo binario. /usr/bin/passwdnecesita modificar /etc/passwdy /etc/shadowque almacena información de cuenta y hashes de contraseña 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:root /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 'música' propiedad del usuario 'root' y el grupo 'ingenieros'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero secundariamente al grupo 'ingenieros' crea un directorio llamado 'electrónico' bajo el directorio llamado 'música'. La propiedad del grupo del nuevo directorio denominado "electrónico" hereda "ingenieros". Esto es lo mismo cuando se crea un nuevo archivo llamado 'imagine.txt'.
Sin SGID, la propiedad del grupo del nuevo directorio/archivo habría sido 'torvalds', ya que ese es el grupo principal de usuarios 'torvalds'.
[ torvalds ~ ] $ grupos torvalds torvalds : ingenieros torvalds[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./music/ 2770 root:engineers ./music/ [torvalds ~] $ mkdir ./music/electronic[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/electronic/ torvalds:engineers ./music/electronic/ [ torvalds ~ ] $ echo 'NUEVO ARCHIVO' > ./music/imagine.txt [ torvalds ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt torvalds:engineers ./music/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 llamado 'videojuegos'. Un usuario llamado 'wozniak', que también forma parte del grupo 'ingenieros', intenta eliminar el archivo llamado 'tekken' pero no puede, ya que no es el propietario.
Sin el bit adhesivo, 'wozniak' podría haber eliminado el archivo, porque el directorio llamado 'videojuegos' permite la lectura y escritura por parte de 'ingenieros'. Se puede ver un uso predeterminado de esto en la /tmpcarpeta.
[ torvalds /home/shared/ ] $ grupos torvalds torvalds : ingenieros torvalds[ torvalds /home/shared/ ] $ 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 /casa/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 el usuario 'root'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero secundariamente al grupo 'ingenieros' crea un archivo o directorio llamado 'pensamientos' dentro del directorio 'blog'. Un usuario llamado 'wozniak' que también pertenece al grupo 'ingenieros' no puede eliminar, cambiar el nombre ni mover el archivo o directorio llamado 'pensamientos' porque no es el propietario y el bit adhesivo está configurado. Sin embargo, si 'pensamientos' es un archivo, entonces 'wozniak' puede editarlo.
Sticky bit tiene la decisión final. Si no se hubieran configurado el bit adhesivo y el SGID, el usuario 'wozniak' podría cambiar el nombre, mover o eliminar el archivo llamado 'pensamientos' porque el directorio llamado 'blog' permite lectura y escritura por grupo, y wozniak pertenece al grupo, y la máscara de usuario predeterminada 0002 permite editar archivos nuevos 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 agregar.
[ torvalds /home/shared/ ] $ grupos torvalds torvalds : ingenieros torvalds[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./blog/ 3171 raíz:ingenieros ./blog/ [ torvalds /home/shared/ ] $ echo 'NUEVO ARCHIVO' > ./blog/thinkings [ torvalds /home/shared/ ] $ su - wozniak Contraseña:[ wozniak ~/ ] $ cd /casa/compartido/blog[ 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 pensamientos rm: no se pueden eliminar 'pensamientos': operación no permitida[ wozniak /home/shared/blog/ ] $ mv pensamientos /home/wozniak/ mv: no se puede mover 'pensamientos' a '/home/wozniak/pensamientos': 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 ¡REESCRIBIR!Los desarrolladores diseñan e implementan cuidadosamente programas que utilizan este bit en ejecutables para evitar vulnerabilidades de seguridad, incluidas saturaciones de búfer e inyección de rutas. Los ataques exitosos de desbordamiento del búfer 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 de hecho le dará al atacante acceso 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 se desinfecta adecuadamente mediante un proceso privilegiado, su comportamiento puede ser modificado por el proceso no privilegiado que lo inició. [8] Por ejemplo, GNU libc fue en un momento vulnerable a un exploit que utilizaba setuiduna variable de entorno que permitía ejecutar código desde bibliotecas compartidas que no eran de confianza . [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 con el número de patente US 4135240 "Protección del contenido de archivos de datos". Posteriormente, la patente pasó a ser de dominio público . [11]