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
siguiente5.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.
© 2002 Antonio Villalón Huerta
