¿Cómo Escribir Programas Seguros? - Verificación exhaustiva y programación conservativa

Es conveniente comprobar siempre el resultado de cualquier llamada a función, aunque se suponga que nunca fallará. El programa debe funcionar adecuadamente siempre, aunque se ejecute bajo circunstancias adversas: sin memoria para los "malloc()", sin descriptores de ficheros libres, con el disco lleno, incapacidad para hacer un "fork()"... En caso necesario el código debe tener pruebas de consistencia interna y hacer logs exhaustivos (cuidado con provocar un buffer overflow en "syslog()"). El código debe releerse varias veces, dejando días entre lecturas y, a ser posible, recurrir a un auditor externo. Estudiar el programa con calma y plantearse "¿Qué ocurre si esta función, que no puede fallar nunca, falla?". Hay que ponerse en la situación de un atacante intentando descubrir una vulnerabilidad en propio código.

En los procesos que se ejecutan con privilegios, la sección crítica de código debe ser lo más pequeña posible, y liberar los privilegios cuanto antes. Cuando sea posible, todos los "paths" a comandos y ficheros deben ser absolutos, y el programa debe fijar su "current directory" de una forma coherente.

El programa debe estar diseñado, también, de forma que se eviten los "deadlocks" (bloqueos) y las "race conditions", y estar preparado para asumir y recuperarse del riesgo de bloqueos permanentes debido a la muerte o al mal funcionamiento de otro proceso. Hay que ser consciente de que cualquier secuencia de eventos dentro de nuestro programa puede ser intercalada con la ejecución de otros procesos. En el caso de GCIs, por ejemplo, hay que ser consciente de que pueden existir múltiples instancias del mismo proceso intentando acceder a recursos comunes. No basta con aplicar bloqueos; dependiendo de la aplicación puede ser preciso definir un mecanismo de limitación de carga: número de instancias concurrentes o segundos de CPU consumidos, por ejemplo.

Cuando se compila el código debe hacerse siempre con el máximo nivel de "warning" que soporte nuestro compilador ya que, en muchas ocasiones, pueden detectarse operaciones incorrectas en tiempo de compilación. Es buena idea también el pasar el código fuente por alguna herramienta de verificación, como "lint".

El programador debe dotar al programa de una documentación detallada del entorno de trabajo, detalles del código y detalles funcionales tales como: instalación, invocación, gestión de señales, opciones de la línea de comando y del fichero de configuración. Cuando se haga uso de algún privilegio especial debe indicarse claramente, así como describir las medidas tomadas para que dichos privilegios no se propaguen en caso de problemas.

Por último, si el proceso se encuentra ante una situación aparentemente inresoluble, que no sea valiente. En casos así el programa debe grabar un log y terminar su ejecución limpiamente, borrando los ficheros temporales, etc. Por nada del mundo debe intentar salvar la situación; hacer funcionar a un programa fuera de sus parámetros operacionales es, en muchas ocasiones, peligroso y más contraproducente que simplemente no correr el servicio.