====== OpenBSD configurando doas ====== {{ :informatica:openbsd:puffy67.gif?380 | OpenBSD-6.7}} La utilidad **doas** viene con páginas man, tanto para el comando **doas** como para el archivo de configuración **doas.conf**, pero algunas personas prefieren un toque más narrativo en su documentación. Así que aquí tenemos una documentación más narrativa, de todos modos. Los sistemas **UNIX** tienen dos clases de usuario, el superusuario y los usuarios normales. El superusuario es **super**, y todos los demás no lo son. Esta concentración de poder mantiene las **cosas simples**, pero también significa que a menudo se otorga demasiado poder. Por lo general, solo necesitamos poderes de superusuario para realizar una tarea. Preferiríamos no tener ese poder todo el tiempo. **¡Piense en la responsabilidad que conlleva!** Al igual que el comando **sudo**, **doas** permite la subdivisión de privilegios de superusuario, otorgándolos solo para tareas específicas. El comando **doas** en sí tiene algunas opciones, que discutiremos más adelante, pero la parte más interesante es el archivo de configuración. Aquí es donde sucede la verdadera magia. ===== doas.conf ===== La configuración **doas.conf** más simple posible es realmente bastante simple. No parpadees o te lo perderás. (vacio) La configuración vacía no hace nada, pero nos permite analizar el conjunto de reglas predeterminado. No hay ninguno. doas comienza a evaluar las reglas en el estado DENY. Si no hay reglas que coincidan, la acción es denegada. Así es. Incluso **root** recibirá un error de permiso denegado. Esto no es particularmente útil, per se, pero se puede estar seguro de que leer el archivo **doas.conf** instalado es suficiente para comprender completamente el comportamiento del sistema. Si no hay ningún archivo de configuración, doas se cerrará después de imprimir un mensaje de que no está habilitado. La configuración útil más simple probablemente se parece más a esto. permit :wheel Esto permite que cualquier usuario en el grupo de **wheel** ejecute cualquier comando como root. Es aproximadamente equivalente al comando su. Para una emulación más completa, nos gustaría permitir que root ejecute comandos sin contraseña. permit :wheel permit nopass keepenv root Agregamos la regla **root** en segundo lugar porque **doas** evalúa las reglas en una última coincidencia. root está en el grupo **wheel**, por lo que la primera regla coincidirá, y luego debemos anular eso con una segunda regla. Recuerde comenzar siempre con reglas generales y luego hacerlas más específicas. ¿Por qué incluso ejecutar *doas* como root? Porque a veces te gustaría cambiar a un usuario menos privilegiado. O bien, tiene un script que utiliza **doas** para elevar los privilegios para una operación importante, pero ya es **root** cuando lo ejecuta. ===== password ===== El comportamiento predeterminado de **doas** es requerir autenticación cada vez que el usuario ejecuta un comando. Normalmente esto significa ingresar su contraseña. Esto puede volverse tedioso si se ejecutan múltiples comandos. Hay dos palabras clave que se pueden agregar a una regla **doas.conf** para modificar este requisito. Agregar la palabra clave **nopass** a una regla significa que el usuario siempre puede ejecutar el comando sin ingresar una contraseña. Hemos visto esto arriba en la regla para **root**. El usuario ya es **root**, por lo que puede hacer lo que quiera y no hay razón para solicitar una contraseña. Al agregar la palabra clave persist (persistir), *doas* recordará que el usuario se autenticó previamente y no requerirá más confirmación por un tiempo de espera de cinco minutos. permit persist :wheel Esta regla recrea la configuración de sudo común de requerir una contraseña para los usuarios de la *wheel* la primera vez que se ejecuta un comando. La información de autenticación que utiliza **doas** se registra en el núcleo y se adjunta a la sesión actual. A diferencia de los tickets del sistema de archivos, no es accesible para otros usuarios y es difícil de falsificar. El tiempo de espera siempre tendrá lugar en tiempo real, no en tiempo de computadora, lo que significa que ajustar el reloj del sistema al revés no puede otorgar una nueva vida a un boleto vencido. Las ejecuciones repetidas restablecerán el tiempo de espera, pero solo si la regla está marcada como persistente (persist). Las reglas no pueden ser tanto **persist** como **nopass**, ni las reglas de *nopass* extenderán el tiempo de espera. Si tiene varios inicios de sesión de shell en una máquina, cada inicio de sesión requerirá autenticación. Además, la información denticacion incluye el ID del proceso de shell principal. Esto significa que ejecutar **doas** nuevamente en un script de shell requerirá autenticación. O, para repetir eso de otra manera, si ejecuta un script o programa de calidad incierta, no podrá elevar silenciosamente los privilegios. (Esa es la teoría de todos modos. En la práctica, la comprobación deja bastante margen de maniobra). permit persist :wheel permit :wheel cmd reboot Las verificaciones de autenticación solo se omiten para las reglas marcadas como persistentes. Para evitar errores, los comandos importantes se pueden volver a enumerar sin persistir para requerir siempre una contraseña. La opción de línea de comando **-L** para **doas** es similar a cerrar sesión e inmediatamente elimina cualquier información de autenticación persistente en este terminal sin esperar el tiempo de espera. ===== Medio ambiente (environment) ===== Hay dos formas básicas de proporcionar información a los comandos ejecutados. La primera y más obvia es la línea de comando. La segunda forma y menos visible es a través de variables de entorno. A pesar de ser principalmente invisibles, las variables de entorno pueden tener efectos dramáticos en el comportamiento de un programa. Por lo tanto, es importante que proporcione algo de filtrado para evitar consecuencias no deseadas. Por defecto, solo se copia una breve lista de variables. Hay dos palabras clave de configuración relacionadas con el entorno, **keepenv** y **setenv**. El primero es muy simple. Lo hemos visto antes, en la regla para el **root** anterior. **keepenv** simplemente significa que todo el entorno debe conservarse y pasarse como está al comando ejecutado. Este es un atajo conveniente para usuarios de confianza. Usar **setenv** es un poco más complicado, ya que permite una combinación de agregar, modificar y eliminar variables de entorno. Veamos un ejemplo. permit setenv { PKG_PATH ENV=/root/.kshrc PS1=$DOAS_PS1 } pedro Esta regla permite al usuario **pedro** ejecutar comandos como **root**. El entorno PKG_PATH se conserva. El entorno ENV, que apunta a un archivo de configuración para **ksh**, se redirige a uno propiedad de **root**. Finalmente, anulamos la configuración de **PS1** que controla la pantalla del prompt de shell. No especificamos el nuevo valor en este archivo de configuración, sino que usamos cualquier valor que esté en **DOAS_PS1**. Esto le permite a **pedro** ajustar el prompt de root como lo desee. ===== Usuarios y objetivos ===== Cada regla en **doas.conf** se aplica a un individuo o grupo, especificado después del permiso y cualquier opción. No hay una palabra clave para distinguir entre usuarios y grupos. En su lugar, se usa una sintaxis similar a **chown**, con nombres de usuario solos o: nombres de grupo con dos puntos iniciales. Ahora es un buen momento para recordar que las reglas siempre se evalúan en orden con la última regla coincidente **ganadora**. Las reglas de usuario específicas no se prefieren automáticamente sobre las reglas de grupo a menos que aparezcan más adelante en el archivo. En la mayoría de las situaciones, **doas** se usa para ejecutar comandos como **root**. Esto no requiere sintaxis adicional. Sin embargo, es posible que también deseemos restringir algunas reglas para que se orienten a ciertos usuarios. permit nopass pedro as dbadmin Esta regla permitirá que **pedro** ejecute comandos como administrador de la base de datos sin ingresar una contraseña, pero por sí solo no permite que **pedro** ejecute nada como **root**. ===== Comandos ===== Nos estamos acercando al final de nuestro recorrido por la sintaxis de **doas.conf**. **Doas** también se puede restringir para que las reglas solo se apliquen a ciertos comandos, o incluso ciertos comandos con argumentos particulares. permit nopass :operator cmd reboot Normalmente, **reboot** requiere privilegios de **root**. En su lugar, se ejecuta indirectamente por el cierre del programa **setuid**, cuya ejecución está restringida al grupo de **operadores**. La regla anterior permite a estos usuarios ejecutar el reinicio directamente. Sin embargo, los operadores no podrán ejecutar otros comandos como **root** u obtener un **shell**. permit pedro cmd sh args /etc/netstart Aquí permitimos que **pedro** vuelva a ejecutar el script **netstart** que configura las interfaces de red. No le damos permiso a **pedro** para ejecutar ningún comando de shell, solo el **script netstart**. En ambos ejemplos, el **cmd** se especificó solo con el **nombre base**. En estos casos, **doas** se limitará a ejecutar solo comandos en la RUTA del sistema /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin **pedro** no podrá instalar un binario sh en su directorio de inicio y establecer PATH en ~/bin para revertir nuestras intenciones. Los nombres de ruta absolutos también se pueden especificar, sin embargo, el usuario también deberá escribirlos en su totalidad. Cualquier argumento de comando especificado debe especificarse en su totalidad. permit pedro cmd ifconfig args iwm0 up permit pedro cmd ifconfig args iwm0 down Estas dos reglas permitirán a **pedro** activar y desactivar la interfaz wifi, pero no cambiar ninguno de sus otros parámetros. Algunas utilidades de usuario que recopilan información del núcleo solo presentan un subconjunto restringido de información cuando son usuarios normales. Para ver la información completa se requiere ejecutar como **root**. Por ejemplo, **fstat** solo imprimirá información mínima sobre los sockets de dominio Unix. pedro Xorg 94581 16* unix stream 0x0 pedro Xorg 94581 17* unix stream 0x0 pedro Xorg 94581 18* unix stream 0x0 pedro Xorg 94581 19* unix stream 0x0 pedro Xorg 94581 20* unix stream 0x0 Pero cuando se ejecuta nuevamente como **root**, vemos mucha más información. pedro Xorg 94581 16* unix stream 0xffff800000b45980 <-> 0xffff800000b3d700 pedro Xorg 94581 17* unix stream 0xffff800000b3d880 <-> 0xffff800000b45500 pedro Xorg 94581 18* unix stream 0xffff800000b45480 <-> 0xffff800000b45300 pedro Xorg 94581 19* unix stream 0xffff800000b45080 <-> 0xffff800000128e80 pedro Xorg 94581 20* unix stream 0xffff800000b60280 <-> 0xffff800000b60780 Esto nos permite hacer coincidir estos sockets con el proceso en el otro extremo. pedro xterm 33159 3* unix stream 0xffff800000b45300 <-> 0xffff800000b45480 pedro Xorg 94581 18* unix stream 0xffff800000b45480 <-> 0xffff800000b45300 Estas direcciones de kernel normalmente están ocultas porque revelan información sobre el diseño de memoria del kernel que puede usarse para facilitar exploits, pero si confiamos en pedro (¿y quién no lo hace realmente?), Entonces podemos cambiar esto con una simple regla de configuración. permit nopass pedro cmd fstat args -u pedro Usando **fstat**, uno siempre puede ver los archivos abiertos de los procesos de otros usuarios, pero aquí especificamos argumentos para evitar que **pedro** haga coincidir las conexiones entre procesos. ===== Negar (Deny) ===== A diferencia de todas las reglas de permisos que hemos visto hasta ahora, también es posible crear una **regla de denegación** que específicamente niega la ejecución de comandos. Esta función es más útil como protección contra errores tipográficos accidentales por parte de operadores de confianza. No debe usarse como una característica de seguridad porque es agotador crear una lista negra exhaustiva. Es mejor crear un conjunto de reglas que no otorgue privilegios involuntarios. permit :wheel deny pedro cmd reboot Suponiendo que **pedro** está en el grupo wheel, le dejaremos ejecutar cualquier comando. Y le denegamos el comando **reiniciar**. Tal vez **pedro** es un gatillo feliz y tiene la costumbre de escribir en el terminal equivocado. Este conjunto de reglas no evitará que **pedro** reinicie la máquina de ninguna manera; la primera regla otorga privilegios suficientes para editar **doas.conf** y eliminar la segunda regla, entre muchas otras posibilidades. La suposición es que todos están en el mismo equipo. ===== doas ===== El comando **doas** en sí tiene algunas opciones. Como acabamos de terminar de ver la sintaxis del archivo de configuración, la opción **-C** se puede usar para verificar la sintaxis de un nuevo archivo antes de instalarlo. También permite verificar el resultado de la evaluación del conjunto de reglas para un comando y argumentos dados sin ejecutar realmente el comando. Continuando con el ejemplo **fstat** de antes, podemos verificar que solo coincida el comando con argumentos. $ doas -C doas.conf fstat deny $ doas -C doas.conf fstat -u pedro permit nopass Al escribir scripts posiblemente no interactivos que incorporan **doas**, la opción **-n** es útil para evitar fallas futuras. Solo las reglas de **nopass** se ejecutarán con éxito. Cualquier regla que requiera una contraseña fallará inmediatamente. Esto incluye cualquier regla con la palabra clave **persist**, independientemente de si el usuario lo autorizó recientemente.