En muchos sistemas, el usuario raíz o superusuario dispone de control total sobre el sistema. Subsistema para aplicaciones UNIX (SUA) no reconoce un usuario raíz. Cuando se desarrolló el estándar Portable Operating System Interface (POSIX), el concepto de usuario raíz se consideraba una cuestión administrativa. En lugar de un usuario raíz, el estándar POSIX define los privilegios adecuados para realizar algunas operaciones.
En este tema
Subsistema para aplicaciones UNIX e identidades
Consideraciones de instalación para setuid en Subsistema para aplicaciones UNIX
setuid y setgid
Los mecanismos setuid y setgid permiten que un programa, cuando se ejecuta, adopte ciertos aspectos de una entidad de seguridad distintos de los del usuario que ejecuta el programa. Estos mecanismos permiten que el programa alterne estos aspectos entre los del usuario que realiza la invocación y los de otra entidad de seguridad.
No es lo mismo que los privilegios adecuados. Mientras que los mecanismos setuid y setgid permiten que una aplicación controle la respuesta a la pregunta "¿Quién eres?", los privilegios adecuados responden a la pregunta "¿Qué puedes hacer?"
Subsistema para aplicaciones UNIX e identidades
En entornos UNIX típicos, hay exactamente un usuario al que se le conceden todos los privilegios. Este usuario, generalmente denominado root, tiene uid == 0. En Subsistema para aplicaciones UNIX, todos los privilegios que se admiten en un sistema determinado se conceden a todos los usuarios que son miembros del grupo Administradores o del grupo Administradores de dominio en dicho sistema. No es necesario iniciar sesión como administrador. Cualquier usuario que sea miembro del grupo Administradores o del grupo Administradores de dominio tiene privilegios root. No todos los privilegios definidos en POSIX o UNIX están disponibles en SUA; es decir, hay ciertos privilegios que no se conceden a ningún usuario.
Los privilegios adecuados suelen ser necesarios para realizar diversidad de acciones. Son necesarios para obtener acceso al sistema de archivos, enviar señales a otros procesos (control de procesos) o para cambiar el identificador de usuario (UID) o identificador de grupo (GID) efectivo de un proceso y, de este modo, cambiar la capacidad de dicho proceso para realizar determinadas acciones.
De acuerdo con el estándar POSIX, un archivo cuenta con permisos que incluyen bits para establecer un UID (setuid) y un GID (setgid). Si se establecen uno o ambos bits en un archivo y un proceso ejecuta dicho archivo, el proceso adquiere el UID o GID del archivo. Si se usa con precaución, este mecanismo permite que un usuario sin privilegios ejecute programas que se ejecutan con los privilegios más elevados del propietario o grupo del archivo. Pero si no se utiliza correctamente, puede presentar riesgos para la seguridad permitir que usuarios sin privilegios realicen acciones que sólo debería realizar un administrador. Por este motivo, SUA no admite este mecanismo de forma predeterminada. En lugar de ello, si se intenta ejecutar un archivo con el bit setuid o setgid establecido, SUA no ejecuta el archivo y devuelve el código de error ENOSETUID.
Consideraciones de instalación para setuid en Subsistema para aplicaciones UNIX
Si depende de una aplicación que requiere un comportamiento POSIX estándar, puede configurar SUA para que ejecute archivos con los bits setuid o setgid establecidos. Si SUA se configura de esta forma, cuando un proceso ejecute un archivo con el bit setuid o setgid establecido, SUA construirá tokens de seguridad local para los procesos con los privilegios asignados al propietario o grupo del archivo. Como los tokens son locales, no son reconocidos por otros equipos de la red. Esto significa que, aunque se archivo pertenezca a un miembro del grupo Administradores de dominio, por ejemplo, el proceso no cuenta con acceso de confianza a otros equipos de este dominio a través de la red de Microsoft® Windows®. En lugar de ello, los privilegios sólo serán efectivos en el equipo en el que se esté ejecutando el proceso.
Por ejemplo, un proceso ejecuta un archivo de programa con su bit setuid establecido y perteneciente a un miembro del grupo Administradores de dominio. Si dicho programa intenta cambiar la contraseña de un usuario de dominio, dicho intento producirá errores porque los tokens de seguridad del proceso son locales y, por lo tanto, otros sistemas del dominio no los reconocen. Por otro lado, si el programa intenta cambiar la contraseña de un usuario local, este intento se realizará correctamente porque el propietario del archivo es miembro del grupo Administradores de dominio, que suele pertenecer al grupo Administradores del equipo local. Para obtener información acerca de la configuración de SUA para ejecutar archivos con los bits setuid o setgid establecidos, vea los archivos de Ayuda que se incluyen con el paquete de descarga de las utilidades y el kit de desarrollo de software (SDK) para Subsistema para aplicaciones UNIX.
En el caso de las funciones setuid(2), setgid(2) y chroot(2), un proceso debe contar con el UID efectivo que vuelva a asignarse a la cuenta del sistema, la cuenta del administrador para el dominio local o la cuenta del administrador para el dominio principal. La cuenta del administrador local sólo puede cambiar el UID o GID a otro ID del mismo dominio.
En el caso de chown(1), chmod(1) y chgrp(1), una cuenta debe disponer de los privilegios SE_BACKUP y SE_RESTORE de Windows para realizar operaciones make en archivos que pertenecen a otro usuario o grupo, o para modificar permisos en un archivo que pertenece a otro usuario. Estos permisos suelen pertenecer a las cuentas del administrador y del operador de copia de seguridad.