Fatmawati Achmad Zaenuri / Shutterstock
SUID, SGID y Sticky Bits son poderosos permisos especiales que puede configurar para ejecutables y directorios en Linux. Compartiremos los beneficios y las posibles dificultades de usarlos.
Ya estan 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, dado que las contraseñas son las claves del reino, deben estar protegidas.
En Linux, las contraseñas almacenadas están protegidas de dos formas: están encriptadas y solo una persona con root
Los privilegios pueden acceder al archivo que contiene las contraseñas. Puede sonar bien, pero presenta un dilema: si solo la gente root
privilegios pueden acceder a las contraseñas almacenadas, ¿cómo pueden aquellos que no tienen este acceso cambiar sus contraseñas?
Eleva tu estatus
Normalmente, los comandos y programas de Linux se ejecutan con el mismo conjunto de permisos que la persona que inicia el programa. Cuando root
ejecutar el passwd
pedido cambiar la contraseña, funciona con root
las autorizaciones de. Esto significa que el passwd
El comando puede acceder libremente a las contraseñas almacenadas en el /etc/shadow
archivar.
Idealmente, habría un esquema en el que cualquiera en el sistema podría ejecutar el passwd
programa, pero tenga el passwd
programa recuerda root
altos privilegios. Esto permitiría a cualquiera cambiar su propia contraseña.
El escenario anterior es precisamente lo que el bit Establecer ID de usuario (SUID
) Acaso. Esta ejecuta programas y comandos con los permisos del propietario del archivo, en lugar de los permisos de la persona que inicia el programa.
Mejoras el estado del programa
Sin embargo, existe otro dilema. Debe evitarse que la persona se entrometa en la contraseña de otra persona. Linux integra 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 la seguridad.
El mecanismo de control que evita que alguien trabaje con la contraseña de otra persona está contenido en el passwd
programa, no 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». Esto significa que la seguridad es lo primero que considera y luego se basa en ella. No escriba su programa, luego intente darle una capa de seguridad.
La mayor ventaja del software de código abierto es puedes mirar el código fuente tú mismo o consulte revisiones de pares de confianza. En el código fuente de passwd
programa, hay comprobaciones, para que pueda ver si la persona que ejecuta el programa es root
. Se permiten diferentes habilidades si alguien está root
(o alguien que usa sudo
).
Este es el código que detecta si alguien está root
.
El siguiente es un ejemplo en el que esto se tiene en cuenta. Porque 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í que para root
, esta omita estas comprobaciones y salga de la función de comprobación.
Con los comandos y utilidades básicos de Linux, puede estar seguro de que tienen seguridad incorporada y de que el código se ha revisado varias 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.
Este es un software de terceros, especialmente aquellos que no son de código abierto, debe tener mucho cuidado al usar SUID
con. No estamos diciendo que no lo haga, pero si lo hace, querrá asegurarse de que no pondrá en riesgo su sistema. No desea elevar los privilegios de un programa que no se va a gobernar a sí mismo correctamente ni a la persona que lo ejecuta.
Comandos de Linux que usan SUID
Estos 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 los archivos 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 leer, escribir y ejecutar. Si las letras están presentes, se ha concedido este permiso. Si un guión (-
) en lugar de una carta, sin embargo, no se ha otorgado este permiso.
Hay tres grupos de estos permisos (de izquierda a derecha): para el propietario del archivo, para los miembros del grupo del archivo y para otros. Cuando el SUID
bit se establece en un archivo, una «s» representa el permiso de ejecución del propietario.
Si la SUID
bit se establece en un archivo que no tiene capacidades ejecutables, una «S» mayúscula indica esto.
Echaremos un vistazo a un ejemplo. Usuario regular dave
Escribelo passwd
pedido:
passwd
los passwd
indicaciones de comando dave
por su nueva contraseña. Podemos usar el ps
pedido para ver los detalles de los procesos actuales.
usaremos ps
con grep
en otra ventana de terminal y búscalo passwd
para tratar. También usaremos el -e
(cada proceso) y -f
(fotograma completo) opciones con ps
.
Escribimos el siguiente comando:
ps -e -f | grep passwd
Se indican dos líneas, la segunda de las cuales es la grep
proceso de búsqueda de comandos que contengan la cadena «passwd». Sin embargo, es la primera línea que nos interesa, porque es la del passwd
para tratar dave
lanza.
Podemos ver el passwd
el proceso es el mismo que si root
lo había lanzado.
Configuración del bit SUID
Es fácil cambiar el SUID
poco con chmod
. los u+s
el modo simbólico define el SUID
pequeño y el u-s
modo simbólico borra el SUID
poco.
Para ilustrar algunos de los conceptos del bit SUID, hemos creado un pequeño programa llamado htg
. Está en el directorio raíz del dave
usuario, y no tiene el SUID
poco asentado. Cuando se ejecuta, muestra los ID de usuario reales y efectivos (UID).
El verdadero UID pertenece a la persona que inició el programa. El ID efectivo es la cuenta con la que el programa se comporta como si se 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
. Así que se comporta como debería hacerlo un programa normal.
Cópialo en el /usr/local/bin
directorio para que otros puedan usarlo.
Escribimos lo siguiente, usando chmod
para configurar el SUID
bit, y luego verifique que se haya establecido:
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 de nuevo, pero esta vez ejecutaremos la copia en el /usr/local/bin
carpetas:
htg
Aunque dave
iniciado el programa, la ID efectiva se establece en el root
usuario. Así que si mary
inicia el programa, ocurre lo mismo que se muestra a continuación:
htg
La verdadera identidad es mary
, y el ID efectivo es root
. El programa se ejecuta con los permisos del usuario root.
Bit SGID
El ID de grupo definido (SGID
) bit es muy similar a SUID
poco. Cuando el SGID
bit se establece en un archivo ejecutable, el grupo efectivo se establece en el grupo de archivos. 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ó.
Hemos afinado nuestro htg
programa para que también muestre el grupo efectivo. Cambiaremos el grupo de htg
programa para ser usuario mary
el grupo predeterminado de, mary
. También usaremos el u-s
y g+s
modos simbólicos con chown
para borrar el SUID
poco y ajustar el SGID
.
Para hacer esto, escribimos lo siguiente:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Puedes ver el SGID
bit indicado por la «s» en los permisos de grupo. También tenga en cuenta que el grupo está configurado para mary
y el nombre del archivo ahora está resaltado en amarillo.
Antes de ejecutar el programa, establezcamos qué grupos dave
y mary
pertenecer. Usaremos el id
orden con el -G
opción (grupos), para imprimir todos los ID de grupo. Entonces ejecutaremos el htg
programa como dave
.
Escribimos los siguientes comandos:
id -G dave
id -G mary
htg
El ID de grupo predeterminado para mary
es 1001, y el grupo efectivo de htg
programa es 1001. Entonces, aunque fue iniciado por dave
, se ejecuta con los permisos de los miembros de la mary
grupo. Es como si dave
se había unido al mary
grupo.
Vamos a aplicarlo SGID
bit en un directorio. Primero, crearemos un directorio llamado «trabajo», luego cambiaremos su grupo a «geek». Luego definiremos el SGID
poco en el directorio.
Cuando usamos ls
para comprobar la configuración del directorio también usaremos el -d
(directorio) para que podamos ver los detalles del directorio, no su contenido.
Escribimos los siguientes comandos:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
los SGID
bit y el grupo «geek» están definidos. Estos afectarán a todos los elementos creados en el work
directorio telefónico.
Escribimos lo siguiente para ingresar al work
directorio, cree un directorio llamado «demo» y verifique sus propiedades:
cd work
mkdir demo
ls -lh -d demo
los SGID
bit y el grupo «geek» se aplican automáticamente al directorio «demo».
Escribamos lo siguiente para crear un archivo con la touch
comando y verifique sus propiedades:
touch useful.sh
ls -lh useful.sh
El grupo del nuevo archivo se establece automáticamente en «geek».
La parte pegajosa
The Sticky Piece recibe su nombre de su propósito histórico. Cuando se establece en un ejecutable, le indica al sistema operativo que las partes de texto del ejecutable deben mantenerse a cambio, lo que acelera 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, los usuarios solo pueden eliminar los archivos que les pertenecen en ese directorio. No pueden eliminar archivos que pertenecen a otra persona, independientemente de la combinación de permisos de archivo establecida en los archivos.
Esto le permite crear un directorio que cualquiera (y los procesos que inician) puede usar como almacenamiento de archivos compartidos. Los archivos están protegidos porque, nuevamente, nadie puede eliminar los archivos de otra persona.
Creemos un directorio llamado «compartido». Usaremos el o+t
modo simbólico con chmod
para establecer el bit adhesivo en este directorio. A continuación, veremos los permisos en ese directorio, así como los /tmp
y /var/tmp
directorios.
Escribimos los siguientes comandos:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Si se establece el bit persistente, el bit ejecutable del conjunto de permisos de archivo «otro» se establece en «t». El nombre del archivo también se resalta en azul.
los /tmp
y /var/tmp
Las carpetas son dos ejemplos de directorios que tienen todos los permisos de archivo establecidos para propietario, grupo y otros (por eso están resaltados en verde). Se utilizan como ubicaciones compartidas para archivos temporales.
Con estos permisos, cualquiera debería, en teoría, poder hacer cualquier cosa. Sin embargo, el bit adhesivo los reemplaza y nadie puede eliminar un archivo que no les pertenece.
Recordatorios
La siguiente es una lista de verificación rápida de lo que hemos cubierto 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 la «
s
«,»g
«, Dónde «t
Los indicadores ”aparecen en mayúsculas, el bit ejecutable (x
) no se ha definido.