¿Alguien puede explicar el mecanismo de configuración de ID de usuario en Unix? ¿Cuál fue la razón detrás de esta decisión de diseño? ¿Cómo es diferente del mecanismo efectivo de identificación de usuario?
12
¿Alguien puede explicar el mecanismo de configuración de ID de usuario en Unix? ¿Cuál fue la razón detrás de esta decisión de diseño? ¿Cómo es diferente del mecanismo efectivo de identificación de usuario?
Es posible que conozca los permisos normales de lectura, escritura y ejecución para archivos en Unix.
Sin embargo, en muchas aplicaciones, este tipo de estructura de permisos, por ejemplo, otorgarle a un usuario dado permiso total para leer un archivo dado, o ningún permiso para leer el archivo, es demasiado burdo. Por esta razón, Unix incluye otro bit de permiso, el set-user-IDbit. Si este bit se establece para un archivo ejecutable, ¡siempre que un usuario que no sea el propietario ejecute el archivo, ese usuario adquiere todos los privilegios de lectura / escritura / ejecución del archivo para acceder a cualquiera de los otros archivos del propietario!
Para establecer el bit set-user-ID para un archivo, escriba
chmod u+s filename
Asegúrese de haber configurado también el permiso de ejecución de grupo-otro; Sería bueno tener también permiso de lectura para otros grupos. Todo esto se puede hacer con la declaración única
chmod 4755 filename
También se conoce como UID guardado. Un archivo que se inicia que tiene un bit Set-UID activado, el UID guardado será el UID del propietario del archivo. De lo contrario, el UID guardado será el UID real.
Este UID se utiliza para evaluar los privilegios del proceso para realizar una acción particular. EUID se puede cambiar a UID real o UID de superusuario si EUID! = 0. Si EUID = 0, se puede cambiar a cualquier cosa.
Un ejemplo de tal programa es passwd. Si lo lista en su totalidad, verá que tiene un bit Set-UID y que el propietario es "root". Cuando un usuario normal, diga "mtk", se ejecuta passwd, comienza con:
Real-UID = mtk
Effective-UID = mtk
Saved-UID = root
man credentialsEs una buena fuente de información en este caso. Vea también esta pregunta sobre SO . Para una explicación histórica, vea esta publicación archivada .
En lugar de llamar "mecanismo UID" y "UID efectivo" a un mecanismo, todo el concepto de UID debería llamarse así. La justificación de la existencia de los diversos UID son varios problemas con la separación de privilegios. Incluso los usuarios habituales (sin privilegios) a veces necesitan hacer cosas (acceder a recursos) que solo los usuarios con privilegios pueden hacer. Para lograr esto fácilmente, los programas pueden cambiar sus UID. Hay 3 tipos de estos:
UID real: el UID que posee un proceso
UID efectivo: el UID con el que se ejecuta actualmente un proceso, esto determina las capacidades reales del proceso en cualquier momento en particular. Esto también es lo que pste muestra en el campo USUARIO.
UID de conjunto guardado: marcador de posición utilizado para alternar entre UID reales y efectivos
La necesidad del último surge del hecho de que los usuarios habituales solo pueden cambiar entre estos tres y nada más, y un programa setuid generalmente necesita saber de alguna manera, quién fue el usuario que lo cargó (más el UID real no debe cambiarse ya que eso crearía un desastre aún mayor).
La expansión de mtk es buena.
El passwdejemplo es uno de escalada de privilegios: passwd siempre se ejecuta como root, ya que debe alterar los archivos que solo la raíz puede modificar. Esto hace que sea importante que el ejecutable passwd no sea propenso a desbordamientos del búfer, etc., de modo que un usuario normal inteligente pueda usarlo para lo que no está destinado.
Otra razón es proteger al usuario de la misma manera que lo haría susi estuviera conectado como root, para disminuir o restringir sus privilegios para tareas específicas, no escalarlos. Por ejemplo, si tengo permiso para iniciar un servicio de daemon que no requiere acceso a mis cosas y tiene sus propias cosas, que es todo lo que necesita (por ejemplo, un registrador), ejecutarlo suid significará que solo tiene acceso a esas cosas y no el mío ni nadie más.
Tenga en cuenta que es posible establecer uid mediante programación incluso si el bit suid no está configurado en el ejecutable , sin embargo, eso no funcionará para la escalada. Es decir, si usted es un usuario normal y escribe un programa que establece uid en algún momento, ese programa no puede cambiar a root. Apache funciona de esta manera, creo. Por lo general, se inicia desde la raíz y tiene un proceso que luego bifurca a los niños que cambian uid a un usuario no privilegiado (por ejemplo, "httpd"). Esos procesos secundarios son los que funcionan en el servidor web real.