13.5 - Permitir a Otros Hacer Operaciones con Privilegios

A menudo se nos pide que creemos una forma de que los usuarios normales hagan cosas que normalmente sólo permite una cuenta administrativa como la de root. Esto puede ser bastante peligroso y debe hacerse con mucho cuidado.

En Unix/Linux, hay un programa llamado sudo que permite a los administradores del sistema dar a una persona la capacidad de ejecutar un comando como otro usuario. Es muy restrictivo, y requiere que el administrador del sistema lo configure para especificar exactamente qué usuario(s) puede(n) ejecutar qué comando(s) como qué otro usuario.

Por ejemplo, puedes configurarlo para permitir que una persona en particular ejecute un comando como root. Puedes confiar en sudo para asegurarte de que sólo las personas que especifiques tengan la capacidad de ejecutar este comando como root, pero es importante que el programa compruebe los parámetros para asegurarse de que los usuarios con privilegios puedan sobrepasar sus límites.

Cualquier tipo de sistema que permita a personas “normales” realizar operaciones “privilegiadas” es un sistema arriesgado de construir. La historia de la seguridad informática está plagada de programadores bienintencionados que crean accidentalmente agujeros de seguridad que permiten a la gente ejecutar cualquier comando como root o administrator.

Si no estás seguro de lo que estás haciendo, investiga los libros de seguridad y las preguntas frecuentes para obtener consejos.

Por ejemplo, si se requiere ser root para ejecutar el comando mount de Unix para acceder a un CD-ROM. Es una mala idea configurar sudo para que la persona pueda ejecutar el comando mount como root con cualquier parámetro. Podría colapsar el sistema o romper la seguridad. Es mucho mejor si configura sudo para que la persona ejecute un nuevo comando (digamos, mountcd) como root. Este comando se asegurará de que él ha especificado las unidades de CD-ROM particulares que el usuario está autorizado a montar (con un valor lógico por defecto), y monta esa unidad. También querrá darle un comando (unmountcd).

Me gusta construir tres capas cuando automatizo algo para otras personas:

  • Capa 1. Un programa que hace la tarea básica.
  • Capa 2. Un programa que el usuario ejecutará, con sudo, que recoge su entrada, la valida, se asegura de que no está tratando de hacer nada sospechoso, y luego llama al primer programa.
  • Capa 3. Una forma más fácil de acceder a estas capas anteriores, como una interfaz web o un programa de menú.

Por ejemplo, en una empresa, teníamos un proceso para lanzar una nueva versión del sitio web de la empresa al mundo. Se trataba de tres servidores web diferentes (en realidad eran servidores virtuales en dos máquinas diferentes, pero esos detalles no son importantes).

www-draft.example.com La siguiente versión de nuestro sitio web se desarrolló aquí.
www-qa.ejemplo.com El borrador del sitio se copiaba aquí para que el departamento de control de calidad lo revisara. Una vez hecha la copia, los archivos se hacían inmediatamente de sólo lectura. Si QA aprobaba este sitio, necesitábamos ser capaces de verificar que estos bits exactos se copiaban en el sitio en vivo.
www.example.com. Este era el sitio en vivo que verían las personas externas.

Los diseñadores de la web pedirían a los administradores del sistema que copiaran su borrador en www-qa.example.com. Cuando el grupo de control de calidad aprobaba el sitio, le decían a los administradores del sistema que lo pusieran en marcha.

Cada una de estas dos funciones estaba automatizada:

readyforqa Copiaba el borrador del sitio al sitio de control de calidad.
golive Copiaba el sitio de control de calidad en el sitio en vivo.

El departamento de marketing exigía una forma de realizar actualizaciones de emergencia cuando el departamento de control de calidad no estaba disponible. Creamos este comando:

emergency-draft-to-live Copiaba el borrador del sitio directamente al sitio en vivo después de preguntar “¿Estás seguro?” unas cuantas veces.

Estos tres scripts constituían la capa 2, que ya he mencionado. La capa 1 era un script que hacía la copia real de los datos de un sitio a otro, haciendo una copia de seguridad en el camino, y estableciendo los archivos de sólo lectura (cambiando la propiedad de los archivos, también). La capa 1 tenía que hacerse como root porque cambiaba la propiedad de los archivos y accedía a las máquinas a través de canales seguros.

Sudo fue programado como se describe en la Tabla 13-1.

Web developers QA Marketing
Readyforqa X X
Golive X
Emergency-draft-to-live. X

Tabla 13-1. Tabla de permisos de actualización de la web

De hecho, nos esforzamos por hacer que la dirección firmara este gráfico, con firmas reales, para asegurarnos de que entendían lo que creían que estaban aceptando. El proceso político para conseguir su aprobación fue la parte más difícil. Llevó semanas. Presentar la información a la dirección en forma de gráfico facilitó mucho la toma de decisiones. Podían entender y actualizar el gráfico ellos mismos hasta que estuvieran contentos con él. Traducir el gráfico final en un archivo de configuración sudo fue la parte fácil.

Por la capa 3, decidimos hacer una forma más fácil para que la gente pueda acceder a estos comandos. Consideramos una interfaz web, pero, en este caso, los usuarios estaban satisfechos con un programa de menú que les presentaba una lista de opciones que ejecutaba el comando apropiado.

El menú se ejecutaba sin ningún privilegio adicional (es decir, no bajo sudo), pero llamaba a los programas de la capa 2 utilizando sudo según fuera necesario.

Volver al índice