Cuando un sistema Unix arranca una de las tareas que obligatoriamente ha de realizar es incorporar diferentes sistemas de ficheros - discos completos, una partición, una unidad de CD-ROM...- a la jerarquía de directorios Unix; este proceso se llama
montaje, y para realizarlo generalmente se utiliza la orden
mount. Es obligatorio montar al menos un sistema de ficheros durante el arranque, el sistema raíz (
`/'), del que colgarán todos los demás.
Montar un sistema de ficheros no significa más que asociar un determinado nombre de directorio, denominado
mount point o punto de montaje, con el sistema en cuestión, de forma que al utilizar dicha ruta estaremos trabajando sobre el sistema de ficheros que hemos asociado a ella. Para saber qué sistemas de ficheros se han de montar en el arranque de la máquina, y bajo qué nombre de directorio, Unix utiliza un determinado archivo; aunque su nombre depende del clon utilizado (
/etc/vfstab en Solaris,
/etc/fstab en Linux...), su función - e incluso su sintaxis - es siempre equivalente. Un ejemplo de este fichero es el siguiente:
luisa:~# cat /etc/fstab
/dev/hda3 / ext2 defaults 1 1
/dev/hda4 /home ext2 defaults 1 2
none /proc proc defaults 1 1
luisa:~#
Cuando el sistema arranque, el fichero anterior viene a indicar que en
/dev/hda3 se encuentra el sistema de ficheros raíz, de tipo
ext2 (el habitual en Linux), y que se ha de montar con las opciones que se toman por defecto. La segunda línea nos dice que
/home es un sistema diferente del anterior, pero del mismo tipo y que se montará con las mismas opciones; finalmente, la última entrada hace referencia al directorio
/proc/, donde se encuentra un sistema de ficheros especial que algunos Unices utilizan como interfaz entre estructuras de datos del núcleo y el espacio de usuario (no entraremos en detalles con él). Si cualquiera de las entradas anteriores fuera errónea, el sistema o bien no arrancaría o bien lo haría incorrectamente. Por lo que evidentemente el fichero
/etc/fstab o sus equivalentes ha de ser sólo modificable por el
root, aunque nos puede interesar - como veremos luego - que los usuarios sin privilegios puedan leerlo.
Lo visto hasta aquí no suele representar ningún problema de seguridad en Unix; si hemos dicho que no hablaríamos de aspectos generales de los sistemas de ficheros, >por qué comentamos este aspecto? Muy sencillo: diferentes problemas radican en una gestión incorrecta del montaje de sistemas de ficheros. Por ejemplo, algo muy habitual en un atacante que consigue privilegios de administrador en una máquina es instalar ciertas utilidades que le permitan seguir gozando de ese privilegio (por ejemplo, un
rootkit o un simple
shell setuidado); si guarda el fichero
setuidado - hablaremos más tarde de estos permisos `especiales' - en cualquier directorio de nuestro sistema, su localización será muy rápida: una orden tan simple como
find nos alertará de su presencia. En cambio, >qué sucede si el atacante utiliza una parte del sistema de ficheros
oculta? Cuando montamos un sistema bajo un nombre de directorio, todo lo que había en ese directorio desaparece de la vista, y es sustituido por el contenido del sistema montado; no volverá a estar accesible hasta que no desmontemos el sistema:
luisa:~# mount
/dev/hda3 on / type ext2 (rw)
/dev/hda4 on /home type ext2 (rw)
none on /proc type proc (rw)
luisa:~# ls /home/
ftp/ toni/ lost+found/
luisa:~# umount /home
luisa:~# ls /home/
luisa:~#
El atacante puede desmontar una parte de nuestra jerarquía de directorios, guardar ahí ciertos ficheros, y volver a montar el sistema que había anteriormente; localizar esos archivos puede ser complicado, no por motivos técnicos sino porque a muy poca gente se le ocurre hacerlo. La orden
ncheck, existente en Unices antiguos, puede detectar estos ficheros ocultos bajo un
mount point; si no disponemos de esta utilidad podemos buscar por Internet aplicaciones que consiguen lo mismo, o simplemente desmontar manualmente los sistemas (a excepción del raíz) y comprobar que no hay nada oculto bajo ellos.
El tema de desmontar sistemas de ficheros también puede ocasionar algún dolor de cabeza a muchos administradores; aunque no se trata de algo estrictamente relativo a la seguridad, vamos a comentar un problema típico que se podría considerar incluso una negación de servicio (no causada por un fallo de Unix sino por el desconocimiento del administrador). En ocasiones, al intentar desmontar un sistema de ficheros, encontramos el siguiente resultado:
luisa:~# umount /home/
umount: /home: device is busy
luisa:~#
>Qué sucede? Simplemente que existe un determinado proceso haciendo uso de recursos bajo ese nombre de directorio. Hasta que dicho proceso no finalice (por las buenas o por las malas), será imposible desmontar el sistema; es fácil determinar de qué proceso se trata - y posteriormente eliminarlo - mediante la orden
fuser.
Otro problema clásico de los sistemas de ficheros viene de la necesidad que en muchos entornos existe de permitir a los usuarios - sin privilegios - montar y desmontar sistemas de ficheros (típicamente, discos flexibles o CD-ROMs). Por ejemplo, imaginemos un laboratorio de máquinas Unix donde es deseable que todos los usuarios puedan acceder a la disquetera, tanto para copiar prácticas realizadas en casa como para hacer una copia de las que se han hecho en el propio laboratorio (este es uno de los casos más frecuentes en cualquier organización). Unix permite dar una solución rápida a este problema, pero esta solución puede convertirse en una amenaza a la seguridad si no es implantada correctamente:
Al hablar de
/etc/fstab hemos comentado el montaje con ciertas opciones tomadas por defecto; dichas opciones son - en el caso de Linux, consultar la página del manual de
mount en otros sistemas -
`rw' (se permite tanto la lectura como la escritura),
`suid' (se permite la existencia de ficheros
setuidados),
`dev' (se permite la existencia de dispositivos),
`exec' (se permite la ejecución de binarios),
`auto' (el sistema se monta automáticamente al arrancar o al utilizar
mount -a),
`nouser' (sólo puede ser montado por el
root) y
`async' (la entrada/salida sobre el dispositivo se realiza de forma asíncrona). Evidentemente, se trata de las opciones más lógicas para sistemas de ficheros `normales', pero no para los que puedan montar los usuarios; si deseamos que un usuario sin privilegios pueda montar y desmontar cierto dispositivo, hemos de especificar la opción
`user' en la entrada correspondiente de
/etc/fstab. Parece lógico también utilizar
`noauto' para que el sistema no se monte automáticamente en el arranque de la máquina (si esto sucediera, el
root tendría que desmontar la unidad manualmente para que otros usuarios puedan montarla), pero otras opciones importantes no son tan inmediatas. Es
imprescindible que si permitimos a un usuario montar una unidad utilicemos
`nodev', de forma que si en el sistema montado existen ficheros de tipo dispositivo (por ejemplo, un archivo que haga referencia a nuestros discos duros) ese fichero sea ignorado; en caso contrario, cualquiera podría acceder directamente a nuestro
hardware, por ejemplo para destruir completamente los discos duros o bloquear toda la máquina. También es importante especificar
`nosuid', de forma que se ignore el bit de
setuid en cualquier fichero contenido en el sistema que el usuario monta: así evitamos que con un simple
shell setuidado en un disco flexible el usuario consiga privilegios de administrador en nuestro sistema. Incluso puede ser conveniente especificar
`noexec', de forma que no se pueda ejecutar nada de lo que está en el dispositivo montado - esto parece lógico, ya que en principio se va a tratar de una unidad utilizada simplemente para transferir datos entre la máquina y un sistema externo a la red, como el ordenador de casa de un alumno -. Todas estas opciones (
`noexec',
`nosuid' y
`nodev') en Linux se asumen simplemente al indicar
`user', pero en otros sistemas Unix quizás no, por lo que nunca está de más ponerlas explícitamente (o al menos consultar el manual en otros clones de Unix para asegurarse del efecto de cada opción); de esta forma, si queremos que los usuarios puedan montar por ejemplo la disquetera, una entrada correcta en
/etc/fstab sería la siguiente:
luisa:~# grep fd0 /etc/fstab
/dev/fd0 /floppy ext2 user,noauto,nodev,nosuid,noexec
luisa:~#
Otro aspecto relacionado con el montaje de sistemas de ficheros que puede afectar a nuestra seguridad es el uso de sistemas de ficheros diferentes del raíz bajo ciertos directorios; una elección incorrecta a la hora de elegir dónde montar sistemas puede causar ciertos problemas, sobre todo negaciones de servicio. Generalmente, es recomendable montar dispositivos diferentes bajo todos y cada uno de los directorios sobre los que los usuarios tienen permiso de escritura; esto incluye el padre de sus
$HOME,
/tmp/ o
/var/tmp/ (que puede ser un simple enlace a
/tmp/). Con esto conseguimos que si un usuario llena un disco, esto no afecte al resto del sistema: un disco lleno implica muchos problemas para la máquina, desde correo electrónico que no se recibe,
logs que no se registran, o simplemente una negación de servicio contra el resto de usuarios, que no podrán almacenar nada. Aunque algunos Unices reservan una parte de cada disco o partición para escritura sólo del
root o de procesos que corran bajo el UID 0 - típicamente un 10% de su capacidad total -, no podemos confiar ciegamente en este mecanismo para mantener segura nuestra máquina; así, una configuración más o menos adecuada sería la siguiente
5.2:
rosita:~# mount
/dev/hda1 on / type ext2 (rw)
/dev/hda2 on /tmp type ext2 (rw)
/dev/hdb1 on /home type ext2 (rw)
none on /proc type proc (rw)
rosita:~#
Como podemos comprobar, si un usuario lanza un
ftp en
background desde su
$HOME durante la noche - típico proceso que llena gran cantidad de disco -, en todo caso podrá afectar al resto de usuarios, pero nunca al sistema en global (correo,
logs,
root...); este tipo de problemas no suelen ser ataques, sino más bien descuidos de los usuarios que no tienen en cuenta el espacio disponible antes de descargar ficheros de forma no interactiva. Si queremos que ni siquiera pueda afectar al resto de usuarios, podemos establecer un sistema de
quotas de disco en nuestra máquina.
