Logo de TuX - Linux Kernel
2 May 2020

Permisos en Linux: Sticky Bit, SUID y SGID

por | publicado en: Arch Linux, CLI, Consola, Debian, Kali Linux, Linux, Manjaro Linux, Sist. Operativos, Terminal, Ubuntu, UNIX, Zentyal | 0
 
 

Índice General

  1. Introducción
  2. Sticky bit (bit de permanencia)
  3. SUID (set user information)
  4. SGID (set group information)
  5. Vulnerabilidades del sistema con SUID y SGID

 

  1. Introducción (Volver al índice General)
    En los sistemas basados en Unix existen tres permisos especiales aplicables a directorios y/o ficheros. A estos permisos se les conoce como sticky bit (bit de permanencia), SUID (Set User ID o setuid) y SGID (Set Group ID o setgid).

    Normalmente, los permisos de los archivos en Unix/Linux se corresponden con un número en octal que varía entre 000 y 777. Sin embargo, estos permisos especiales varían ese número octal entre 0000 y 7777.

    • Sticky bit: 1000.
    • SGID: 2000.
    • SUID: 4000.

    Estos permisos pueden resultarnos útiles para determinadas tareas, como por ejemplo, a la hora de compartir directorios o archivos entre diferentes usuarios o permitir a los usuarios del sistema ejecutar binarios con privilegios elevados temporalmente, para realizar tareas específicas.

    2.  

  2. Sticky bit (bit de permanencia) (Volver al índice General)
    El permiso Sticky bit se asigna sumándole 1000 a la representación octal de los permisos de un fichero o directorio y otorgándole además permiso de ejecución para el resto de usuarios (otros).

    Si el Sticky bit de un fichero está activado le estamos indicando al sistema operativo que se trata de un archivo muy utilizado, por lo que es conveniente que permanezca en memoria principal el mayor tiempo posible. Esta opción se utilizaba en sistemas antiguos que disponían de muy poca RAM, pero hoy en día prácticamente no se utiliza. Lo que si que sigue vigente es su utilización en directorios.

    Este permiso suele asignarse a directorios a los que todos los usuarios tienen acceso. Evita que un usuario pueda borrar o renombrar elementos pertenecientes a otro usuario, dentro de ese directorio, es decir, los elementos que hay en un directorio al que se asigna el permiso Sticky bit, sólo pueden ser renombrados o borrados por el propietario del elemento, el propietario del directorio o el usuario root, aunque el resto de usuarios tengan permisos de escritura.

    Directorios donde solemos encontrar asignado este permiso son /tmp y /var/tmp.

    El directorio /tmp tiene permisos 777. Para asignarle el permiso sticky bit ejecutaríamos el siguiente comando:

    $ sudo chmod 1777 /tmp

    O también:

    $ sudo chmod o+t /tmp

    Para quitarlo, ejecutamos el siguiente comando:

    $ sudo chmod o-t /tmp

    O también, añadiendo un 0 al principio de la notación octal:

    $ sudo chmod 0777 /tmp

    Tras asignar el sticky bit, si ejecutamos el comando ls, observamos que el directorio tmp en lugar de una «x» en la terna correspondiente al resto de usuarios (otros) aparece una «t». Vamos a ver un ejemplo, pero filtramos con grep para que no nos liste todos los directorios:

    $ ls -l / | grep tmp
drwxrwxrwt  26 root root 20480 abr 22 14:35 tmp

    Si asignamos el sticky bit a un elemento y no le damos permiso de ejecución, aparecerá una «T». Por ejemplo, creemos dos archivos:

    $ touch /tmp/archivo{1,2}

    Al archivo1 le asignaremos permisos de ejecución y el sticky bit:

    $ chmod 1777 /tmp/archivo1

    Y al archivo2 no asignaremos permiso de ejecución al resto de usuarios (otros) pero si el sticky bit:

    $ chmod 1776 /tmp/archivo2

    Si listamos ambos archivos, veremos que en la tercera terna de permisos, archivo1 en lugar de una «x» aparece una «t» y que archivo2 en lugar de una «x» aparece una «T»:

    $ ls -l /tmp/ejemplo*
-rwxrwxrwt 1 filemon filemon 0 abr 22 21:48 /tmp/archivo1
-rwxrwxrwT 1 filemon filemon 0 abr 22 21:48 /tmp/archivo2

    Nota: Si aparece una «T» en la tercera terna de permisos, sticky bit no está activado.


    3.  
     
     

  3. SUID (set user information) (Volver al índice General)
    El permiso SUID o setuid se asigna sumándole 4000 a la representación octal de los permisos de un archivo y otorgándole además, permiso de ejecución al propietario del mismo. Al hacer esto, en lugar de la «x» en la primera terna de los permisos, aparecerá una «s», o una «S» si no hemos otorgado el permiso de ejecución correspondiente, en este caso, el permiso no tiene efecto.

    Cuando el permiso SUID está activado en un fichero, el usuario que ejecute el fichero tendrá durante la ejecución los mismos privilegios que el propietario del fichero.
    Por ejemplo, si el administrador (root) crea un fichero y le activa el permiso SUID, todo usuario que lo ejecute dispondrá de privilegios de administrador hasta que el programa finalice.

    Supongamos que tenemos el archivo programa.sh, cuyo propietario es root y pertenece al grupo root, además, tiene permisos de ejecución para el propietario, el grupo y para el resto de usuarios (otros):

    $ sudo chmod 755 programa.sh

    Lo listamos para comprobar los cambios:

    $ ls -l programa.sh 
-rwxr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Para asignar el permiso SUID a un fichero podemos ejecutar los siguiente comandos:

    $ sudo chmod u+s programa.sh

    O también:

    $ sudo chmod 4755 programa.sh

    Si listamos el archivo, observamos que en la primera terna de permisos, la «x» cambia por una «s»:

    $ ls -l programa.sh
-rwsr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Para quitarlo, podemos ejecutar los siguientes comandos:

    $ sudo chmod u-s programa.sh

    O también:

    $ sudo chmod 0755 programa.sh

    Si listamos el archivo, observamos que en la primera terna de permisos, la «s» vuelve a ser una «x»:

    $ ls -l programa.sh
-rwxr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Si no hemos otorgado el permiso de ejecución correspondiente, en este caso, el permiso SUID no tiene efecto y en vez de una «s» aparecerá una «S». En el siguiente ejemplo, asignaremos el permiso SUID pero no el permiso de ejecución:

    $ sudo chmod 4655 programa.sh

    Si listamos el archivo, observamos que en la primera terna de permisos, la «s» pasa a ser una «S»:

    $ ls -l programa.sh
-rwSr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Nota: Si aparece una «S» en la primera terna de permisos, SUID no está activado.

    Ejemplos de ficheros ejecutables con el permiso SUID son su y password. Si listamos ambos ficheros podemos obervar que en la primera terna de permisos en vez de una «x» aparece una «s»:

    $ ls -l passwd su
-rwsr-xr-x 1 root root 63736 jul 27  2018 passwd
-rwsr-xr-x 1 root root 63568 ene 10  2019 su


    4.  
     
     

  4. SGID (set group information) (Volver al índice General)
    El permiso SGID o setgid se asigna sumándole 2000 a la representación octal de los permisos de un archivo y otorgándole además, permiso de ejecución al grupo del mismo. Al hacer esto, en lugar de una «x» en la segunda terna de los permisos, aparecerá una «s», o una «S» si no hemos otorgado el permiso de ejecución correspondiente, en este caso, el permiso SGID no tiene efecto.

    Si el permiso SUID permitía que el proceso adquiriera los permisos del propietario del fichero ejecutado, SGID hace lo mismo pero adquiriendo los privilegios del grupo asignado al fichero. También es asignable a directorios.

    Volvamos con nuestro archivo programa.sh, cuyo propietario es root y pertenece al grupo root, además, tiene permisos de ejecución para el propietario, el grupo y para el resto de usuarios (otros):

    $ sudo chmod 755 programa.sh

    Lo listamos para comprobar los cambios:

    $ ls -l programa.sh 
-rwxr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Para asignar el permiso SGID a un fichero podemos ejecutar los siguiente comandos:

    $ sudo chmod g+s programa.sh

    O también:

    $ sudo chmod 2755 programa.sh

    Si listamos el archivo, observamos que en la segunda terna de permisos, la «x» cambia por una «s»:

    $ ls -l programa.sh
-rwxr-sr-x 1 root root 0 abr 29 17:07 programa.sh

    Para quitarlo, podemos ejecutar los siguientes comandos:

    $ sudo chmod g-s programa.sh

    O también:

    $ sudo chmod 0755 programa.sh

    Si listamos el archivo, observamos que en la segunda terna de permisos, la «s» vuelve a ser una «x»:

    $ ls -l programa.sh
-rwxr-xr-x 1 root root 0 abr 29 17:07 programa.sh

    Si no hemos otorgado el permiso de ejecución correspondiente, en este caso, el permiso SGID no tiene efecto y en vez de una «s» aparecerá una «S». En el siguiente ejemplo, asignaremos el permiso SGID pero no el permiso de ejecución:

    $ sudo chmod 2745 programa.sh

    Si listamos el archivo, observamos que en la segunda terna de permisos, la «s» pasa a ser una «S»:

    $ ls -l programa.sh
-rwxr-Sr-x 1 root root 0 abr 29 17:07 programa.sh

    Nota: Si aparece una «S» en la seguna terna de permisos, SGID no está activado.

    Si en vez de un fichero se tratase de un directorio, el permiso SGID se aplicará a los ficheros y subdirectorios que se creen en él, los cuales tendrán como grupo propietario el mismo que el del directorio que se aplica el permiso SGID, siempre y cuando el proceso que los cree pertenezca a dicho grupo.
    Es un permiso muy útil cuando varios usuarios de un mismo grupo necesitan trabajar con recursos dentro de un mismo directorio (directorios compartidos).

    Por ejemplo, supongamos que tenemos la carpeta /home/mortadelo/comun que pertenece al usuario y grupo mortadelo, con permisos 770 (rwxrwx—) y el permiso SGID:

    mortadelo@mipc:~$ mkdir /home/mortadelo/comun && chmod 2770 /home/mortadelo/comun

    Si listamos el directorio, veremos el permiso SGID asignado:

    $ ls -l /home/mortadelo/comun | grep comun
drwxrws--- 2 mortadelo mortadelo 4096 abr 30 17:30 comun

    Si creamos un fichero dentro del directorio con un usuario distinto a mortadelo, al tener activado el permiso SGID, este asignará al fichero el grupo mortadelo en vez del grupo del usuario que lo creó. Vamos a crear un archivo en el directorio con el usuario root:
    Adquirimos privilegios de root::

    $ su

    Con el usuario root: creamos el archivo:

    # touch /home/mortadelo/comun/prueba.txt

    Si listamos el directorio /home/mortadelo/comun, observamos que el archivo recién creado no tiene como grupo el de root, sino el de mortadelo:

    $ ls -l /home/mortadelo/comun
total 0
-rw-r--r-- 1 root mortadelo 0 may  1 14:04 prueba.txt


    5.  
     
     

  5. Vulnerabilidades del sistema con SUID y SGID (Volver al índice General)
    Los permisos SUID y SGID habrán de utilizarse con extremo cuidado. Por un lado otorgan flexibilidad al sistema mientras que por otro, constituyen una debilidad del mismo.

    Los archivos ejecutables con el permiso SUID o SGID se ejecutan con los privilegios de quien los creó. Si los creó un administrador (root), cualquier usuario que los ejecute podría lanzar tareas que no controle el sistema operativo.

    Podemos hacernos una idea con el siguiente ejemplo. Crearemos un fichero ejecutable que presente el UID y EUID (Effective UID) del usuario que lo ejecuta:

    Crearemos el fichero con el código fuente testsuid.c:

    $ nano testsuid.c

    Añadimos al fichero el siguiente código fuente en lenguaje C:

    #include <stdio.h>
#include <unistd.h>
 
main(){
  printf("UID: %d, EUID: %d\n",getuid(),geteuid());
}

    Lo compilamos como root dándole el nombre testsuid:

    $ cc -o testsuid testsuid.c

    Asignamos como propietario y grupo a root:

    $ sudo chown root:root testsuid

    Le asignamos el permiso SUID:

    $ sudo chmod u+s testsuid

    Comprobamos los cambios:

    $ ls -l testsuid
-rwsr-xr-x 1 root root 16712 abr 29 18:12 testsuid

    Comprobamos cual es nuestro UID con el comando id:

    mortadelo@mipc:~$ id
uid=1000(mortadelo) gid=100(mortadelo) groups=100(users)

    Ejecutamos el archivo testsuid con un usuario normal, en este ejemplo será el usuario mortadelo:

    mortadelo@mipc:~$ ./testsuid
UID: 1000, EUID: 0

    Podemos ver que el usuario sin privilegios especiales mortadelo, cuando ejecuta el programa testsuid está trabajando con un EUID (Effective UID) 0, lo que le otorga los permisos del root (administrador), ya que éste último es el propietario del ejecutable.

    Si el ejecutable con el permiso SUID activado fuera una shell (intérprete de comandos), el usuario mortadelo tendría todos los privilegios del root hasta que finalice la ejecución de la shell, lo cual supone un agujero de seguridad grandísimo.

    Una forma de localizar ficheros con los permisos SUID o SGID activados, es ejecutar el siguiente comando como root (por aquello de tener acceso a todos los directorios desde el raíz):

    # find / \( -perm -4000 -o -perm -2000 \) -type f -print

Sabiendo que el equivalente octal de los permisos en Unix/Linux puede variar entre 0000 y 7777 y como hemos visto en los puntos anteriores, que podemos sumar 4000, 2000 o 1000 a los permisos normales para activar respectivamente los permisos SUID, SGID y Sticky bit, podemos activar varios permisos especiales a la vez simplemente sumando sus valores. Por ejemplo, para asignar todos los permisos especiales a un fichero con la terna octal de permisos 777, tendríamos que sumarar 7000 a la terna octal 777:

$ sudo chmod 7777 programa.sh

Si listamos el archivo, veremos que tiene activados todos los permisos especiales:

$ ls -l programa.sh 
-rwsrwsrwt   1 root     root            0 abr 29 17:07 programa.sh

 

Espero que este artículo os haya sido de utilidad. Si pensáis que podéis colaborar para mejorar este artículo, que hay algo erróneo en él o simplemente deseáis comentarlo, por favor, dejad vuestra opinión más abajo.
  Configuración de privacidad y de cookies.
Seguir J. Carlos:

Técnico Informático - Desarrollo Web - Administración de Redes

Técnico Informático. Desarrollo Web. Administración de redes.

Últimas publicaciones de

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.