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.

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.

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.

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.

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.

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.

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.

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.