Los indicadores de derechos de acceso de Unix setuid y setgid (abreviatura de "establecer ID de usuario" y "establecer ID 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 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 asumidos o de identificación de grupo proporcionados no siempre son elevados, como mínimo son específicos.
Los indicadores setuid
y setgid
son necesarios 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 ping
comando, que debe enviar y escuchar paquetes de control en una interfaz de red.
Efectos
Los indicadores setuid
y setgid
tienen diferentes efectos, dependiendo de si se aplican a un archivo, a un directorio o un archivo ejecutable binario o un archivo ejecutable no binario. Los indicadores setuid
y solo setgid
tienen efecto en archivos ejecutables binarios y no en scripts (por ejemplo, Bash, Perl, Python). [3]
Cuando se establece en un archivo ejecutable
Cuando los atributos setuid
o setgid
se configuran en un archivo ejecutable , cualquier usuario capaz de ejecutar el archivo ejecutará automáticamente el archivo con los privilegios del propietario del archivo (comúnmente raíz ) y / o el grupo del archivo, dependiendo de las banderas establecidas. [2] Esto permite al diseñador del sistema permitir que se ejecuten programas confiables que, de otro modo, un usuario no podría ejecutar. Puede 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 necesite hacer ping a otro sistema pueda hacerlo, incluso si su propia cuenta no tiene el privilegio requerido para enviar paquetes.
Por razones de seguridad, el usuario que invoca se prohíbe generalmente por el sistema de alterar el nuevo proceso de ninguna manera, como por ejemplo mediante el uso de ptrace
, LD_LIBRARY_PATH
o el envío de señales a la misma, para explotar el privilegio elevado, aunque todavía se aceptarán señales de la terminal.
Los bits setuid
y setgid
normalmente se establecen con el comando chmod
estableciendo el dígito octal de orden superior en 4 para setuid
o 2 para setgid
. " " establecerá los bits y (4 + 2 = 6), haciendo que el archivo sea de lectura / escritura / ejecutable para el propietario (7) y ejecutable por el grupo (primero 1) y otros (segundo 1). Cuando un usuario que no sea el propietario ejecuta el archivo, el proceso se ejecutará con los permisos de usuario y grupo establecidos por su propietario. Por ejemplo, si el archivo es propiedad de un usuario y un grupo , se ejecutará independientemente de quién lo ejecute.chmod 6711 file
setuid
setgid
root
wheel
root:wheel
La mayoría de las implementaciones del chmod
comando también admiten argumentos simbólicos más detallados para establecer estos bits. El modo preferiblemente de grano más fino se muestra en la siguiente demostración como " chmod ug+s
"
Impacto de seguridad
Si bien la setuid
función es muy útil en muchos casos, su uso inadecuado puede representar un riesgo de seguridad [2] si el setuid
atributo se asigna a programas ejecutables que no están diseñados cuidadosamente. Debido a posibles problemas de seguridad, [4] muchos sistemas operativos ignoran el setuid
atributo cuando se aplican a scripts de shell ejecutables .
La presencia de setuid
ejecutables explica por qué la chroot
llamada al sistema no está disponible para usuarios no root en Unix. Consulte las limitaciones dechroot
para obtener más detalles.
Cuando se establece en un directorio
Establecer el setgid
permiso en un directorio (" chmod g+s
") hace que los nuevos archivos y subdirectorios creados dentro de él hereden su ID de grupo , en lugar de la ID de grupo principal del usuario que creó el archivo (la ID de propietario nunca se ve afectada, solo la ID de grupo) .
- Los subdirectorios recién creados heredan el
setgid
bit. Por lo tanto, esto permite un espacio de trabajo compartido para un grupo sin el inconveniente de requerir que los miembros del grupo cambien explícitamente su grupo actual antes de crear nuevos archivos o directorios. - solo afecta al ID de grupo de los nuevos archivos y subdirectorios creados después de que
setgid
se establece el bit, y no se aplica a las entidades existentes. - no afecta el ID de grupo de los archivos que se crean en otro lugar y se mueven al directorio en cuestión. El archivo seguirá llevando el ID de grupo que se efectuó cuando y donde se creó.
La configuración del setgid
bit en subdirectorios existentes debe hacerse manualmente, con un comando comofind /path/to/directory -type d -exec chmod g+s '{}' \;
El setuid
permiso establecido en un directorio se ignora en la mayoría de los sistemas UNIX y Linux . [ cita requerida ] Sin embargo, FreeBSD puede configurarse para interpretar setuid
de una manera similar a setgid
, en cuyo caso obliga a todos los archivos y subdirectorios creados en un directorio a ser propiedad del propietario de ese directorio, una forma simple de herencia. [5] 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 setgid
bit estuviera siempre 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". [6]
Ejemplos de
Comprobando permisos
Los permisos de un archivo se pueden verificar en forma octal y / o alfabética con la herramienta de línea de comando stat
[torvalds ~] $ stat -c "% a% A" ~ / test / 1770 drwxrwx - T
SUID
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á establecido (el '1') para que 'thompson' pueda ejecutar el archivo. El propietario del archivo es 'root' y el permiso SUID está establecido (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 a los que el usuario normalmente no estaría autorizado, sin darle al usuario acceso de root completo.
Un uso predeterminado de esto se puede ver con el /usr/bin/passwd
archivo binario. /usr/bin/passwd
necesita modificar /etc/passwd
y /etc/shadow
almacenar la información de la cuenta y los 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 root: root / usr / bin / passwd[thompson ~] $ passwd passwd: Cambio de contraseña para thompson
El propietario del proceso no es el usuario que ejecuta el archivo ejecutable, sino el propietario del archivo ejecutable.
SGID
2770 en un directorio llamado 'música' propiedad del usuario 'root' y del grupo 'ingenieros'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero en segundo lugar al grupo 'ingenieros' crea un directorio llamado 'electrónico' bajo el directorio llamado 'música'. La propiedad del grupo del nuevo directorio denominado "electrónica" 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 de torvalds[torvalds ~] $ stat -c "% a% U:% G% n" ./music/ 2770 root: ingenieros ./music/[torvalds ~] $ mkdir ~ / música / electrónica[torvalds ~] $ stat -c "% U:% G% n" ./music/electronic/ torvalds: ingenieros ./music/electronic/[torvalds ~] $ echo 'NUEVO ARCHIVO' > ./music/imagine.txt[torvalds ~] $ stat -c "% U:% G% n" ./music/imagine.txt torvalds: ingenieros ./music/imagine.txt[torvalds ~] $ toque ~ / prueba[torvalds ~] $ stat -c "% U:% G% n" ~ / prueba torvalds: torvalds ~ / prueba
Poco pegajoso
1770 en un directorio denominado 'videojuegos' propiedad del usuario 'torvalds' y del 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 sticky bit, 'wozniak' podría haber eliminado el archivo, porque el directorio llamado 'videojuegos' permite la lectura y escritura por parte de 'ingenieros'. Un uso predeterminado de esto se puede ver en la /tmp
carpeta.
[torvalds / home / shared /] $ grupos torvalds torvalds: ingenieros de torvalds[torvalds / home / shared /] $ stat -c "% a% U:% G% n" ./videogames/ 1770 torvalds: ingenieros ./videogames/[torvalds / home / shared /] $ echo 'NUEVO ARCHIVO' > videojuegos / tekken[torvalds / home / shared /] $ su - wozniak Contraseña:[wozniak ~ /] $ grupos wozniak wozniak: ingenieros de wozniak[wozniak ~ /] $ cd / home / shared / videogames[wozniak / home / shared / videogames /] $ rm tekken rm: no se puede eliminar 'tekken': operación no permitida
Poco pegajoso con SGID
3171 en un directorio llamado 'blog' propiedad del grupo 'ingenieros' y el usuario 'root'
Un usuario llamado 'torvalds' que pertenece principalmente al grupo 'torvalds' pero en segundo lugar 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 borrar, renombrar o mover el archivo o directorio llamado 'pensamientos', porque él 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 han establecido 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 leer y escribir por grupo, y wozniak pertenece al grupo, y la umask 0002 predeterminada permite editar nuevos archivos por grupo. Sticky bit y SGID se pueden combinar con algo como una máscara de usuario de solo lectura o un atributo de solo adición.
[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 / home / shared / 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 pueden mover 'pensamientos' a '/ home / wozniak / pensamientos': Operación no permitida[wozniak / home / shared / blog /] $ mv pensamientos ponderando mv: no se puede mover 'pensamientos' a 'ponderación': operación no permitida[wozniak / home / shared / blog /] $ echo '¡REESCRIBIR!' > pensamientos[wozniak / home / shared / blog /] pensamientos de $ cat ¡REESCRIBIR!
Seguridad
Los desarrolladores diseñan e implementan programas que utilizan este bit en ejecutables con cuidado para evitar vulnerabilidades de seguridad, incluidos los desbordamientos del búfer y la inyección de rutas . Los ataques exitosos de saturación 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 setuid
bit para ejecutarse root
, el código se ejecutará con privilegios de root, lo que le dará al atacante acceso de root al sistema en el que se está ejecutando el proceso vulnerable.
De particular importancia en el caso de un setuid
proceso es el entorno del proceso. Si el entorno no se desinfecta adecuadamente mediante un proceso privilegiado, su comportamiento puede ser cambiado por el proceso sin privilegios que lo inició. [7] Por ejemplo, GNU libc fue en un momento vulnerable al uso de exploitssetuid
y una variable de entorno que permitía ejecutar código desde bibliotecas compartidas que no eran de confianza . [8]
Historia
La setuid
broca fue inventada por Dennis Ritchie [9] e incluida en su
. [9] Su empleador, entonces Bell Telephone Laboratories , solicitó una patente en 1972; la patente fue otorgada en 1979 con el número de patente US 4135240"Protección del contenido del fichero de datos". Posteriormente, la patente pasó a ser de dominio público . [10]
Ver también
- Identificador de usuario
- Identificador de grupo
- Identificador de proceso
chmod
sudo
- Problema de diputado confundido
- PolicyKit
- Seguridad Unix
- Revocación de privilegios (informática)
- Separación de privilegios
Referencias
- ↑ von Hagen, William (13 de mayo de 2010). Biblia de Ubuntu Linux . págs. 3–59. ISBN 9780470881804.
- ^ a b c {{cit e libro | primero = Æleen | último = Frisch | título = Administración esencial del sistema | url = https://books.google.com/books?id=uRW8V9QOL7YC&q=setuid&pg=PT375 | page = 351 | publisher = O'Reilly | isbn = 9780596550493 | date = 2009-02-09}}
- ^ Billimoria, Kaiwan N. (2018). Programación práctica del sistema con Linux: Explore las interfaces, la teoría y la práctica de la programación del sistema Linux . Packt Publishing Ltd. pág. 250. ISBN 978-1-78899-674-7.
- ^ "Unix - Preguntas frecuentes" .
- ^ "chmod - cambiar modos de archivo" . freebsd.org .
- ^ "open, openat - abre o crea un archivo para leer, escribir o ejecutar" . freebsd.org .
- ^ Neil Brown (23 de noviembre de 2010). "Fantasmas del pasado de Unix, parte 4: diseños de alto mantenimiento" . LWN.net . Consultado el 30 de marzo de 2014 .
- ^ Jake Edge (27 de octubre de 2010). "Dos vulnerabilidades glibc" . LWN.net . Consultado el 30 de marzo de 2014 .
- ^ a b McIlroy, M. Douglas (1987). Un lector de investigación Unix: extractos comentados del Manual del programador, 1971–1986 (PDF) (Informe técnico). CSTR. Bell Labs. 139.
- ^ "Resumen de patentes de software clave" .
enlaces externos
- Chen, Hao; Wagner, David ; y Dean, Drew; Setuid desmitificado (pdf)
- Tsafrir, Dan; Da Silva, Dilma ; y Wagner, David; La turbia cuestión de cambiar la identidad del proceso: desmitificar la revisión de Setuid (pdf)
- Pollock, Wayne; Modos y permisos de archivos y directorios de Unix