En 1990 Barton P. Miller y un grupo de investigadores publicaron
[MFS90], un artículo
en el que se mostraba que demasiadas herramientas estándar (más del 25%)
de Unix fallaban ante elementos tan simples como una entrada anormal. Cinco
años más tarde otro grupo de investigación, dirigido también por Barton
P. Miller, realizó el estudio [MKL$^+$95], lamentablemente no publicado;
las conclusiones en este último estudio fueron
sorprendentes: el sistema con las herramientas más estables era Slackware
Linux, un Unix gratuito y de código fuente libre que presentaba una tasa de
fallos muy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de
este hecho anecdótico, era preocupante comprobar como la mayoría de
problemas descubiertos en 1990 seguía presente en los sistemas Unix
estudiados.
Aunque por fortuna la calidad del software ha mejorado mucho en los
últimos años6.1, y esa mejora lleva asociada una
mejora en la robustez del código, los fallos y errores de diseño en
aplicaciones o en el propio núcleo son una de las fuentes de amenazas a la
seguridad de todo sistema informático. Pero no
sólo los errores son problemáticos, sino que existen programas - como los
virus - realizados en la mayoría de situaciones no para realizar tareas
útiles sino para comprometer la seguridad de una máquina o de toda una red.
Este tipo de programas sólamente compromete la seguridad cuando afectan al
administrador; si un virus infecta ficheros de un usuario, o si éste ejecuta
un troyano, sólo podrá perjudicarse a sí mismo: podrá borrar sus
ficheros, enviar correo en su nombre o matar sus procesos, pero no hacer lo
mismo con el resto de usuarios o el root. El problema para la seguridad
viene cuando es el propio administrador quien utiliza programas contaminados
por cualquier clase de fauna, y para evitar esto hay una medida de protección
básica: la prevención. Es crucial que las actividades como
administrador se reduzcan al mínimo, ejecutando como usuario normal
las tareas que no requieran de privilegios. Cuando no quede más remedio que
trabajar como root (por ejemplo a la hora de instalar software
en el sistema), no hemos de ejecutar nada que no provenga de una
fuente fiable, e incluso así tomar precauciones en caso de que el programa
realice funciones mínimamente delicadas para el sistema operativo (por
ejemplo, probarlo antes en una máquina de testeo, o en entornos cerrados con
chroot()). Es muy normal, sobre todo entre administradores de Linux, el
recomendar que no se ejecute nada sin haber leído previamente el código
fuente, o al menos que dicho código esté disponible; esto, aunque es una
solución perfecta al problema, es inaplicable en la mayoría de
situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su
código abierto a sus usuarios, por lo que nos estaríamos restringiendo a
utilizar programas generalmente no comerciales - algo que quizás no depende
de nosotros, como administradores -. Por otro, resulta absurdo pensar que un
administrador tenga el tiempo necesario para leer (y lo más importante, para
comprobar) cada línea del código de todos los programas instalados
en sus máquinas.
© 2002 Antonio Villalón Huerta
