ResponTodo

SUID, SGID y Sticky Bits son poderosos permisos especiales que puede establecer para ejecutables y directorios en Linux. Compartiremos los beneficios y los posibles obstáculos de usarlos.

Ya están en uso

La integración de la seguridad en un sistema operativo multiusuario presenta varios dilemas. Tome el concepto (aparentemente) básico de contraseñas, por ejemplo. Todos deben almacenarse para que cada vez que alguien inicie sesión, el sistema pueda comparar la contraseña que escribe con la copia almacenada. Obviamente, como las contraseñas son las claves del reino, deben protegerse.

En Linux, las contraseñas almacenadas están protegidas de dos maneras: están encriptadas y solo alguien con rootprivilegios puede acceder al archivo que contiene las contraseñas. Eso puede sonar bien, pero presenta un dilema: si solo las personas con  root privilegios pueden acceder a las contraseñas almacenadas, ¿cómo pueden cambiar sus contraseñas quienes no tienen ese acceso?

Elevando tu estatus

Por lo general, los comandos y programas de Linux se ejecutan con el mismo conjunto de permisos que la persona que inicia el programa. Cuando rootejecuta el passwdcomando para cambiar una contraseña , se ejecuta con rootlos permisos de. Eso significa que el passwdcomando puede acceder libremente a las contraseñas almacenadas en el /etc/shadowarchivo.

Lo ideal sería un esquema en el que cualquier persona del sistema pudiera iniciar el passwdprograma, pero que el passwdprograma conservara rootlos privilegios elevados. Esto permitiría a cualquiera cambiar su propia contraseña.

El escenario anterior es precisamente lo que hace el bit Establecer ID de usuario ( SUID). Se lleva a cabo programas y comandos con los permisos del propietario del archivo, en lugar de los permisos de la persona que inicia el programa.

Estás elevando el estado del programa

Sin embargo, existe otro dilema. Debe evitarse que la persona se entrometa en la contraseña de otra persona. Linux incorpora el SUID esquema que le permite ejecutar aplicaciones con un conjunto de permisos prestados temporalmente, pero eso es solo la mitad de la historia de seguridad.

El mecanismo de control que evita que alguien trabaje con la contraseña de otra persona está contenido en el passwdprograma, no en el sistema operativo y el esquema SUID.

Los programas que se ejecutan con privilegios elevados pueden presentar riesgos de seguridad si no se crean con una mentalidad de «seguridad por diseño». Eso significa que la seguridad es lo primero que considera y luego se basa en eso. No escriba su programa y luego intente darle una capa de seguridad después.

La mayor ventaja del software de código abierto es  que puede ver el código fuente usted mismo  o consultar revisiones de pares confiables. En el código fuente del passwdprograma, hay comprobaciones, para que pueda ver si la persona que ejecuta el programa es root. Se permiten diferentes capacidades si alguien lo está root(o alguien lo está usando sudo).

Este  es el código que detecta si alguien lo está root.

El siguiente es un ejemplo en el que se tiene en cuenta. Como root puede cambiar cualquier contraseña, el programa no tiene que preocuparse por las comprobaciones que suele realizar para ver qué contraseñas tiene permiso para cambiar la persona. Así, por root, que  se salta los controles y sale de la función de comprobación .

Con los comandos y utilidades principales de Linux, puede estar seguro de que tienen la seguridad incorporada y que el código se ha revisado muchas veces. Por supuesto, siempre existe la amenaza de exploits aún desconocidos. Sin embargo, los parches o actualizaciones aparecen rápidamente para contrarrestar cualquier vulnerabilidad recientemente identificada.

Es software de terceros, especialmente cualquiera que no sea de código abierto, debe tener mucho cuidado al usarlo SUID. No estamos diciendo que no lo haga, pero, si lo hace, querrá asegurarse de que no expondrá su sistema a riesgos. No desea elevar los privilegios de un programa que no va a autogobernarse correctamente a sí mismo y a la persona que lo ejecuta.

Comandos de Linux que usan SUID

Los siguientes son algunos de los comandos de Linux que usan el bit SUID para otorgar privilegios elevados al comando cuando lo ejecuta un usuario normal:

ls -l / bin / su

ls -l / bin / ping

ls -l / bin / mount

ls -l / bin / umount

ls -l / usr / bin / passwd

Tenga en cuenta que los nombres de archivo están resaltados en rojo, lo que indica que el bit SUID está establecido.

Los permisos sobre un archivo o directorio suelen estar representados por tres grupos de tres caracteres: rwx. Estos significan lectura, escritura y ejecución. Si las cartas están presentes, se ha concedido ese permiso. Sin embargo, si hay un guión ( -) en lugar de una letra, no se ha otorgado ese permiso.

Hay tres grupos de estos permisos (de izquierda a derecha): aquellos para el propietario del archivo, para los miembros del grupo del archivo y para otros. Cuando el SUIDbit se establece en un archivo, una «s» representa el permiso de ejecución del propietario.

Si el SUIDbit se establece en un archivo que no tiene capacidades ejecutables, una «S» mayúscula lo indica.

Veremos un ejemplo. El usuario regular dave escribe el passwdcomando:

passwd

El passwdcomando solicita davesu nueva contraseña. Podemos usar el pscomando para ver los detalles de los procesos en ejecución .

Usaremos ps con grep en una ventana de terminal diferente y buscaremos el passwdproceso. También usaremos las opciones -e(cada proceso) y -f(formato completo) con ps.

Escribimos el siguiente comando:

ps -e -f | grep passwd

Se informan dos líneas, la segunda de las cuales es el grepproceso que busca comandos con la cadena «passwd» en ellos. Sin embargo, es la primera línea que nos interesa porque es la del passwdproceso  daveiniciado.

Podemos ver que el passwdproceso se ejecuta igual que si lo  root hubiera iniciado.

Configuración del bit SUID

Es fácil cambiar la  SUIDbroca con  chmod. El u+smodo simbólico establece el SUIDbit y el u-smodo simbólico lo borra SUID.

Para ilustrar algunos de los conceptos del bit SUID, creamos un pequeño programa llamado htg. Está en el directorio raíz del daveusuario y no tiene el SUIDbit configurado. Cuando se ejecuta, muestra los ID de usuario ( UID ) reales y efectivos .

El UID real  pertenece a la persona que lanzó el programa. El ID efectivo es la cuenta con la que se comporta el programa como si lo hubiera iniciado.

Escribimos lo siguiente:

ls -lh htg

./htg

Cuando ejecutamos la copia local del programa, vemos que los ID reales y efectivos están configurados en dave. Por lo tanto, se está comportando como debería hacerlo un programa normal.

Copiemos en el /usr/local/bindirectorio para que otros puedan usarlo.

Escribimos lo siguiente, usando  chmodpara configurar el SUIDbit, y luego verificamos que se haya configurado:

sudo cp htg / usr / local / bin

sudo chmod u + s / usr / local / bin / htg

ls -hl / usr / local / bin / htg

Entonces, el programa se copia y se establece el bit SUID. Lo ejecutaremos nuevamente, pero esta vez ejecutaremos la copia en la /usr/local/bincarpeta:

htg

Aunque se haya  daveiniciado el programa, el ID efectivo se establece en el rootusuario. Entonces, si mary inicia el programa, sucede lo mismo, como se muestra a continuación:

htg

La identificación real es maryy la identificación efectiva es root. El programa se ejecuta con los permisos del usuario root.

El bit SGID

El SGIDbit Establecer ID de grupo ( ) es muy similar al SUIDbit. Cuando el SGIDbit se establece en un archivo ejecutable, el grupo efectivo se establece en el grupo del archivo. El proceso se ejecuta con los permisos de los miembros del grupo del archivo, en lugar de los permisos de la persona que lo inició.

Ajustamos nuestro htgprograma para que también muestre el grupo efectivo. Cambiaremos el grupo del htgprograma para que sea el marygrupo predeterminado del usuario mary. También usaremos los modos simbólicos u-sy g+scon  chown para eliminar el SUIDbit y establecer el SGID.

Para hacerlo, escribimos lo siguiente:

sudo chown root: mary / usr / local / bin / htg

sudo chmod us, g + s / usr / local / bin / htg

ls -lh / usr / local / bin / htg

Puede ver el SGIDbit indicado por la «s» en los permisos de grupo. Además, tenga en cuenta que el grupo está configurado en mary y el nombre del archivo ahora está resaltado en amarillo.

Antes de ejecutar el programa, vamos a establecer qué grupos  davey marypertenecen a. Usaremos el idcomando con la -Gopción (grupos) para imprimir todos los ID de grupo . Luego, ejecutaremos el htgprograma como  dave.

Escribimos los siguientes comandos:

id -G dave

id -G maría

htg

El ID del grupo predeterminado para mary es 1001, y el grupo efectivo del htgprograma es 1001. Entonces, aunque fue lanzado por dave, se está ejecutando con los permisos de los miembros del marygrupo. Es lo mismo que si se davehubiera unido al marygrupo.

Apliquemos el SGIDbit a un directorio. Primero, crearemos un directorio llamado «trabajo» y luego cambiaremos su grupo a «geek». Luego, estableceremos el SGIDbit en el directorio.

Cuando usamos ls para verificar la configuración del directorio, también usaremos la -dopción (directorio) para que veamos los detalles del directorio, no su contenido.

Escribimos los siguientes comandos:

sudo mkdir trabajo

sudo chown dave: trabajo friki

sudo chmod g + s trabajo

ls -lh -d trabajo

Se establecen el grupo de SGIDbits y «geek». Esto afectará a los elementos creados dentro del workdirectorio.

Escribimos lo siguiente para ingresar al workdirectorio, creamos un directorio llamado «demo» y verificamos sus propiedades:

trabajo en cd

demo de mkdir

ls -lh -d demo

El SGIDbit y el grupo «geek» se aplican automáticamente al directorio «demo».

Escribamos lo siguiente para crear un archivo con el touchcomando y verifiquemos sus propiedades:

toque útil.sh

ls -lh útil.sh

El grupo del nuevo archivo se establece automáticamente en «geek».

El pedacito pegajoso

El bit pegajoso recibe su nombre de su propósito histórico. Cuando se configura en un ejecutable, indica al sistema operativo que las partes de texto del ejecutable deben mantenerse en intercambio , lo que agiliza su reutilización. En Linux, el bit pegajoso solo afecta a un directorio; configurarlo en un archivo no tendría sentido.

Cuando establece el bit de pegamento en un directorio, las personas solo pueden eliminar archivos que les pertenecen dentro de ese directorio. No pueden eliminar archivos que pertenecen a otra persona, sin importar qué combinación de permisos de archivo se establezca en los archivos.

Esto le permite crear un directorio que todos, y los procesos que inician, pueden usar como almacenamiento de archivos compartidos. Los archivos están protegidos porque, nuevamente, nadie puede borrar los archivos de otra persona.

Creemos un directorio llamado «compartido». Usaremos el o+tmodo simbólico con chmodpara establecer el bit adhesivo en ese directorio. Luego veremos los permisos en ese directorio, así como los  directorios /tmpy /var/tmp.

Escribimos los siguientes comandos:

mkdir compartido

sudo chmod o + t compartido

ls -lh -d compartido

ls -lh -d / tmp

ls -lh -d / var / tmp

Si se establece el bit adhesivo, el bit ejecutable del «otro» conjunto de permisos de archivo se establece en «t». El nombre del archivo también se resalta en azul.

Las carpetas /tmpy /var/tmpson dos ejemplos de directorios que tienen todos los permisos de archivo establecidos para el propietario, el grupo y otros (por eso están resaltados en verde). Se utilizan como ubicaciones compartidas para archivos temporales.

Con esos permisos, cualquiera debería, en teoría, poder hacer cualquier cosa. Sin embargo, el bit pegajoso los anula y nadie puede eliminar un archivo que no le pertenece.

Recordatorios

La siguiente es una lista de verificación rápida de lo que cubrimos anteriormente para referencia futura:

• SUID solo funciona en archivos.
• Puede aplicar SGID a directorios y archivos.
• Solo puede aplicar el bit adhesivo a los directorios.
• Si los indicadores » s«, » g» o » t» aparecen en mayúsculas, el bit ejecutable ( x) no se ha establecido.