15 de Junio, 2004

Controlando los recursos: disk quota

Recientemente se ha descubierto una denegación de servicio local en Linux. Es decir, si tenemos acceso shell a una máquina con un kernel Linux sin parchear, pues la podemos tirar abajo.

Leía en slashdot y a cuento de este tema que es fácil tirar una máquina Linux abajo si tenemos acceso local (por ejemplo un bucle infinito de llamadas a fork, no nos referimos a empujar a la CPU de la mesa al suelo :D). Es cierto, pero no es culpa del kernel, ni de la distribución siquiera. Puede que sea culpa del administrador.

En blackshell tengo algunos usuarios que tienen correo. No disponen de cuenta shell, solo acceso al SMTP y POP3 mediante un túnel desde elxwifi (o POP3s desde Internet). Incluso en estas circunstancias podrían intentar 'tirar' a blackshell abajo. Llenando el disco, por ejemplo.

El correo, por lo general, suele almacenarse en /var/mail. Si uno de mis usuarios decidiera hacer crecer su buzón de forma incontrolada, otros procesos que emplean la partición donde se encuentra /var podrían empezar a sufrir problemas.

¿Cómo se puede evitar esto? Vamos a tomar al usuario fulanito como ejemplo ;) y a ver los mecanismos que proporciona OpenBSD (BSD quotas, imagino que disponible en cualquier UNIX):

# quota fulanito
Disk quotas for user fulanito (uid 1003):
Filesystem  blocks  quota  limit grace files quota \
limit grace
/storage     16     25600  25650       1     0     \
0

He tenido que editar un poco la salida de quota para que sea legible en el post.

El usuario fulanito tiene límite en el sistema de archivos montado en /storage (he sido descubierto, el correo de blackshell no está en /var :D). La cuota está en unos 25MBs (los valores están en bloques de 1K) y sobrepasado ese límite el usuario será avisado. El límite indicado por limit, ligeramente superior, indica el valor que nunca será sobrepasado (con errores, y no avisos, indicando que el disco está lleno). Se puede dar un periodo de gracia (grace) pasado el cual el límite inferior (softlimit o límite flexible) se comporta como el superior (hardlimit o límite rígido). Además vemos otros datos, como el número de ficheros en uso y tal.

Las cuotas son fáciles de configurar.

Primero hay que asegurarse de que tenemos soporte en el kernel y que nuestro sistema de archivos en uso soporta esta característica. En OpenBSD con el kernel GENERIC ambas cosas son siempre ciertas.

Editamos /etc/fstab:

...otras cosas sin importancia...
/dev/wd1a /storage ffs rw,nodev,nosuid,softdep,\
userquota=/var/quotas/quota-user.storage 1 2

He puesto la barra invertida para acortar un poco la linea. Editando fstab nunca lo haremos, ojo.

Junto a la parafernalia habitual de fstab vemos que una de las opciones es userquota y que apunta al fichero donde se gestionarán los límites por usuario. Estos ficheros van habitualmente en la raíz del punto de montaje donde aplicamos los límites. He empleado un sitio no estándar para que quede la cosa más ordenada. groupquota nos permite cambiar la localización del fichero para los límites por grupo.

Por defecto las cuotas se activan en el arranque del sistema (vía /etc/rc.conf.local con check_quotas=YES), pero podemos activarlas y desactivarlas con:

# quotaon -a
# quotaoff -a

Por último solo nos queda editar los límites para grupos y usuarios con edquota. Si ejecutamos edquota fulanito tenemos:

Quotas for user fulanito:
/storage: blocks in use: 16, limits (soft = 25600, hard = 25650)
        inodes in use: 1, limits (soft = 0, hard = 0)

El funcionamiento es como el editor vi. Cambiamos los valores para soft y hard como hemos visto más arriba, recordando que los valores se representan en bloques de 1KB. Se supone que algo de vi sí pilotamos, ¿no? :D.

Hay otras herramientas para manejar las cuotas, pero con esto creo que ya he dado una visión general del invento. Para más información la página del manual de quota es un buen punto de partida.

Bueno, y ahora algún lector avispado podría plantear que con limitar el uso del disco no es suficiente. En caso de acceso shell a la máquina, ¿qué hacer contra un fork sin control? Para eso está /etc/login.conf, que ya lo dejamos para otro día ;).

Anotación por Juan J. Martínez.

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.