Enjaulando usuarios cual vulgares animalejos …

… es sólo cuestión de decidirse por el método: suave o por las bravas.

A riesgo de padecer algún tipo de implosión cerebral voy a volver a hablar del acceso de usuarios para copias de seguridad y la propia seguridad del servidor.

Es algo cansino, lo sé, pero cuanto más me adentro en la construcción de algo sencillo más me percato de lo que estoy omitiendo. Linux tiene un mecanismo bastante bueno para enjaular la actividad de un usuario conectado al mismo e impedir que acceda a ciertos archivos y/o ejecute determinados programas: se llama chroot; no es perfecto, hay varias formas de saltárselo, pero es un buen primer paso para asegurar el sistema.

Como el sistema de copias que estoy construyendo y retocando necesita un acceso seguro y discreto opté por las conexiones vía SSH. Y hasta aquí muy bien, porque ya dije cómo conseguir perfiles de usuario ceñidos a un propósito, pero luego me he encontrado con varios detalles que me están complicando la vida.

  1. Cómo accede el usuario al sistema
  2. Quién activa la jaula
  3. Qué puede ejecutar allí y cuáles son sus límites

La respuesta a la primera pregunta ya está contestada: SSH. Y tiene también la posibilidad de activar la jaula para el usuario pero está muy limitada en cuanto a qué se puede ejecutar después; básicamente un programa para la copia vía scp y sftp. Si quieres algo más entonces debes cambiar el enfoque: dejar acceso al usuario y limitar a nivel de cuenta la interacción con el sistema. Dado que lo habitual es emplear un shell existe uno adaptado justo a lo que queremos: rssh.

Empleando esta herramienta como shell de usuario se abren más posibilidades, más protocolos de transferencia de datos, pero el mecanismo tiene un precio: el programa auxiliar que utiliza para activar la jaula debe ser propiedad de root y tener activo el bit SUID correspondiente.

Esto supone un riesgo de seguridad, pero dado que rssh funciona bajo el identificador del usuario que acaba de conectarse, y debe activar la jaula, no hay otra opción.

Otra de las limitaciones de emplear rssh es que los usuarios deben tener definido su directorio de trabajo con la ruta completa de la jaula. Esto es, si una cuenta tiene su directorio home en /home/usuario, y la jaula está en /chroot, se debe dar de alta como /chroot/home/usuario.

La razón para ello es que estamos empleando SSH para acceder al sistema y la jaula sólo se monta cuando se ha producido la conexión; para el resto del sistema cualquier cosa relacionada con el usuario (como claves de acceso SSH) debe ser accesible directamente.

Resumiendo: SSH proporciona el acceso y la transmisión de datos y rssh el entorno de ejecución limitado en espacio y en herramientas.

Hay más documentación al respecto en el repositorio donde mantengo el software: https://git.astillas.net/msat/tree/topics/sb.