Particiones recomendadas en LINUX
/var
Una de las incidencias más frecuentes que ocurre en un sistema en producción, aun siendo
fácilmente evitable, es el llenado al 100% de un sistema de ficheros y que ya no quede
espacio disponible para escribir nuevos datos en él. De forma similar a como ocurre en un
barco, que un compartimento se inunde puede ser algo muy desagradable, pero si el
sistema está bien compartimentado el problema no pasará a mayores. Por el contrario, si
no hay esta separación en compartimentos estancos, la inundación afectará a todo el
conjunto y el barco se hundirá. De la misma manera, si nuestro sistema tiene una única
partición y ésta se llena completamente, las aplicaciones no podrán seguir escribiendo
datos a disco, por lo que pueden producirse todo tipo de situaciones con resultados
imprevisibles, desde corrupción de datos por no poderse volcar el contenido de las cachés
a disco, aplicaciones que dejan de funcionar por no poder escribir sobre ficheros temporales
necesarios para su funcionamiento, o directamente el colapso de todo el sistema por no
poder seguir funcionando correctamente el sistema operativo.
El directorio /var es el más representativo de esta situación por ser el utilizado para
almacenar los ficheros de log del sistema. Por tanto, es típicamente de los que más
escrituras recibe y el de mayor ritmo de incremento, por lo que si no se le presta la debida
atención puede llegar fácilmente al límite de ocupación de la partición que lo aloja. Así, si
no se separa del resto es fácil que en algún momento podamos sufrir una caída total del
sistema.
/tmp
Tux over disk partition diagramAparte de los problemas de denegación de servicio o de
corrupción de datos mencionados en el punto anterior, hay problemas inherentes a la
seguridad que se pueden atajar tan solo con configurar ciertas opciones de montaje en un
sistema de ficheros. Por ejemplo, podemos anular ciertos tipos comunes de ataque
impidiendo que se pueda establecer el flag setuid en los permisos de un fichero mediante
la opción de montaje nosuid, se puede impedir la creación de ficheros de dispositivo con la
opción nodev, o se puede impedir la ejecución de programas no permitiendo la activación
del permiso de ejecución (x) en ningún fichero con noexec.
Todas estas opciones son altamente recomendables especialmente en el caso de /tmp, ya
que por su naturaleza es un directorio al que puede acceder sin restricciones cualquier
usuario del sistema, pues tiene permisos 777 o -rwxrwxrwx. Por tanto, es un blanco fácil
para que un atacante instale software malicioso en él y desde ahí pueda comprometer otras
partes del sistema.
Al margen de la seguridad, puede resultar muy interesante de cara al rendimiento montar
el directorio /tmp sobre un sistema de ficheros en memoria en lugar de en disco. Dado que
muchas aplicaciones lo usan habitualmente para su funcionamiento normal, su rendimiento
se verá mejorado si pueden leer los ficheros directamente desde la memoria RAM, mucho
más rápida. Al final del artículo presento una propuesta de esquema de particionamiento
teniendo en cuenta todos estos conceptos y principios, y en ella puede verse cómo montar
el /tmp en memoria.
/home
Al igual que en el caso de /var, el directorio /home puede crecer sin control debido que es
el lugar donde los usuarios almacenan sus documentos, y a no ser que establezcamos un
sistema de cuotas, éstos pueden fácilmente llenarlo por completo, ya sea de forma
voluntaria o involuntaria. Esto provocaría el colapso del sistema si no lo llevamos a una
partición aparte. Pero además, precisamente porque es otro lugar donde los usuarios
pueden escribir libremente, también ofrece peligros potenciales parecidos a los de /tmp,
por lo que es recomendable establecer las opciones de montaje nosuid y nodev. La
activación de la opción noexec dependerá del uso que se les vaya a permitir hacer a los
usuarios de su directorio personal. Desde luego a priori sería mejor no permitirles ejecutar
ningún programa, pero en muchas ocasiones será legítimo que los usuarios puedan hacerlo,
y de hecho puede ser un requisito imprescindible.
Lo que sí es conveniente entonces es activar las opciones acl y user_xattr para poder
establecer reglas de control de acceso a los ficheros más sofisticadas y hacer uso de los
atributos extendidos de usuario.
/boot
En /boot están alojados tanto el cargador de arranque del sistema como los distintos
kernels que tengamos instalados en nuestro sistema. Su contenido no se utiliza en la
operación normal del sistema, sólo en el arranque del mismo, y debe poder ser leída
directamente por la BIOS para la máquina pueda arrancar correctamente. Este
requerimiento hace por tanto imprescindible tener una partición dedicada para /boot en
algunos casos, por ejemplo, si estamos usando volúmenes RAID o LVM y nuestra BIOS no
soporta el arranque directo desde ese tipo de volúmenes, o si necesitamos que el sistema
de ficheros raíz (/) esté encriptado, pues tanto el bootloader como el kernel no pueden ser
cifrados y deben ser accesibles de forma sencilla y directa por la BIOS. También si la BIOS es
antigua puede tener la limitación de que la partición de arranque sólo pueda ocupar los
primeros 1.024 cilindros de disco, por lo que si nuestro disco es muy grande esta limitación
puede hacer obligatorio que disponer de una partición pequeña al comienzo del disco sobre
la que montar el directorio /boot.
En sistemas más modernos que disponen de UEFI en sustitución de la antigua BIOS es
necesario disponer de una partición formateada con sistema de ficheros FAT32 o vfat en
/boot/efi para cumplir con el estándar EFI y poder almacenar distintos cargadores de
arranque y drivers que permitan que la máquina pueda arrancar múltiples sistemas
operativos.
Por tanto, aunque no es imprescindible en la mayoría de los casos, sí es recomendable
disponer de una partición dedicada para /boot y otra para /boot/efi para tener mayor
flexibilidad a la hora de hacer cambios sobre un sistema existente. Desde el punto de vista
de la seguridad también nos puede servir para aplicar una capa adicional de protección
montando los sistemas de ficheros /boot y /boot/efi como sólo lectura con la opción de
montaje ro, o directamente no montarlos (opción noauto), ya que como decía al principio
sólo se necesitan en el arranque y no durante el funcionamiento normal. De esta forma un
atacante no podría alterar el arranque del sistema, y aunque el sistema de permisos de
Linux ya se encarga de impedir cualquier modificación a usuarios que no sean root, esto es
como digo una capa adicional de seguridad.
/usr
La razón más interesante por la que separar el sistema de ficheros /usr es poder establecer
opciones de montajes nodev o errors=remount-ro, lo que permitirá que se monte en modo
sólo lectura si se produce algún error en el arranque del sistema y aumentar así las
probabilidades de que un sistema defectuoso llegue a arrancar y nos permita intentar
recuperarlo y/o salvar cierta información.
Es importante señalar que en algunas distribuciones como Fedora se está haciendo un
esfuerzo por modificar el estándar de facto que suponía tener algunos directorios como
/bin o /lib colgando directamente de / y llevarlos a través de un enlace simbólico a /usr/lib
o /usr/bin. Por tanto, en estos casos puede no ser recomendable separar /usr y mantenerlo
en la misma partición que /.
/data
Imaginemos que necesitamos almacenar información con características muy específicas
que hagan recomendable usar un sistema de ficheros distinto al habitual ext4, por ejemplo.
Imaginemos que necesitamos montar un servidor de ficheros destinado a almacenar
archivos de gran tamaño como vídeos o fichero .[Link] de gran tamaño. En ese caso puede
resultar más indicado usar un sistema de ficheros que ofrezca un mejor rendimiento a la
hora de manejar ficheros de gran tamaño, como por ejemplo XFS. También podríamos
encontrarnos en la necesidad de usar alguna de las características específicas para las que
han sido optimizados otros sistemas de ficheros, como la posibilidad de tomar snapshots o
instantáneas de nuestros datos, compresión de datos de forma transparente, o
desfragmentación en línea, para lo cual usaríamos otros tipos de filesystems como ZFS o
BtrFS.
swap
Aunque es posible establecer áreas de intercambio o swap directamente en ficheros y
almacenarlos en cualquiera de los directorios del sistema, lo más habitual es destinar una
partición específicamente para este cometido, lo cual tiene la ventaja de poder llevar el
área de intercambio a otro dispositivo más adecuado. Por ejemplo, si para nosotros es muy
importante minimizar la penalización de rendimiento que se produce cuando el sistema de
queda sin memoria RAM y comienza a paginar o “swapear”, podríamos llevar la partición
de swap a un disco SSD a pesar de que hoy por hoy eso suponga acortarle la vida. Por el
contrario, si nuestra máquina dispone de memoria RAM de sobra, podemos destinar los
discos SSD a otras particiones donde su uso será más productivo y utilizar un disco
magnético de bajo coste para el área de intercambio, ya que su uso será más infrecuente al
no haber escasez de RAM.
Sistema de ficheros raíz o /
Por último, y a propósito del sistema de ficheros raíz, me gustaría puntualizar que no todos
los directorios que cuelgan de / son susceptibles de ser separados en distintas particiones.
Hay directorios como /etc, /lib o /bin que nunca deben ubicarse en particiones separadas y
deben ser todos parte de este sistema de ficheros ráiz.
Otros motivos por los que establecer un esquema de particionamiento
Además de las ventajas ya expuestas en puntos anteriores, crear un buen esquema de
particionamiento puede ofrecernos posibilidades adicionales:
Flexibilidad
Es posible que nos equivoquemos en nuestra previsión inicial en cuanto al espacio que va a
ser necesario destinar a cada una de las particiones de nuestro esquema de
particionamiento, pero al mismo tiempo esto nos proporcionará de gran flexibilidad a la
hora de redimensionar el espacio cuando detectemos que una partición se nos queda corta
o que por el contrario tiene demasiado espacio que nunca llegaremos a utilizar.
Redundancia de datos
Hay sistemas de ficheros que puede ser necesario duplicar (mirroring), o que requieran
incluso el uso de algún sistema de ficheros distribuido como GlusterFS o CephFS,
Sistema de ficheros en red
Mediante el uso de herramientas como Samba o NFS es posible compartir en red el
contenido de un sistema de ficheros. Aunque es posible compartir sólo una parte de él, es
decir, un subdirectorio, esto hace más complicado gestionar la seguridad y es más
recomendable emplear una partición específica para este cometido.
