Como parte de la seguridad lógica, es evidente que la seguridad cobra gran importancia en lo que a software se refiere. No solo es peligroso un software mal escrito, algunos programas maliciosos pueden ser usados para permitir franquear la "puerta" de nuestro sistema con mayor facilidad.
Con respecto a la seguridad en los programas si tiene mucho que decir Linux con respecto a otros sistemas operativos. De todos es conocido que en casi cualquier otro sistema operativo ( por lo menos los que no siguen un desarrollo paralelo a Linux ) un fallo en un programa ha de ser comunicado a la empresa propietaria del operativo y de ella dependerá en mayor medida la escritura de un parche o conjunto de parches que den una solución a la brecha de seguridad abierta en nuestro sistema.
La unica solución que tenemos ante un problema de este tipo, es tratar de rescindir el servicio o de protegerlo mientras no es parcheado. Aquí aparece una de las grandes ventajas del software de fuente libre, si en un programa de este tipo aparece un fallo de seguridad nosotros mismos podremos tratar de escribir un parche para el mismo y si no lo hacemos nosotros existirá una amplia comunidad de desarrolladores que se pondrán manos a la obra de modo que el tiempo de aparición del parche será mucho mas rapida y la rescisión del servicio se hará durante mucho menos tiempo
Existe una única manera de tener nuestro sistema seguro de fallos dependientes del software. Esta manera no es ni más ni menos que estar informados en todo momento de los cambios y los fallos de seguridad de los programas que tenemos instalados en nuestros sistema bien para ponerlos fuera de servicio bien para estar informados de los parches que salen para los mismos. Una muy buena regla para el mantenimiento de nuestro sistema es estar actualizado en todo momento.
A lo largo de la programación en un sistema *nix se repiten una serie de patrones que a pesar de no ser los únicos son fallos que se observan regularmente en los programas para *nix ( e incluso para otros operativos ), como muestra hablaremos de los desbordamientos de pila ( Stack Overflow ) y de los "tmpraces" o "races" ya que son dos de los fallos de seguridad más significativos.
Comencemos con los "stacks overflow", estos fallos vienen de la mano de un desbordamiento de pila. El método seguido es el siguiente, se trata por algun método de desbordar la pila de un proceso que corre en estos momentos como otro usuario distinto al nuestro ( generalmente el administrador del sistema ), lo que conseguiremos al desbordar la pila del proceso es que se ejecute la direccion almacenada en la pila antes de que se haya producido el desbordamiento, de modo que se ejecutará lo que hemos introducido en esa dirección. Cuando estos fallos ocurren corremos el peligro que codigo arbitario sea colocado en esa dirección de la pila para ser ejecutado de forma arbitaria
Hemos de ser conscientes que la ejecución de codigo arbitario por parte de un programa que esta siendo ejecutado como superusuario puede dar lugar a fallos tan importantes como por ejemplo que el codigo ejecutado sea /bin/sh con las credenciales de root, tomando así el intruso que ha utilizado el fallo contra nuestro programa el control total de la maquina
Estos fallos son productos de malos habitos de programación como el no chequear longitudes de parametros, cadenas que van a ser pasadas a una función, etc...
Otro fallo habitual en programación es el de permitir los llamados "tempraces". Es común que algunos programas creen ficheros temporales para cualquier uso en su ejecución sin embargo también es común que se creen con un nombre fijo y el algunos casos ni tan siquiera se compruebe si existe ya este fichero. Estos malos usos de programación pueden dar lugar a comprometer la estabilidad del sistema. Imaginemos que /tmp que es donde ususalmente se crean estos archivos pertenece la partición / , de modo que podremos crear un "hard link" por ejemplo con /etc/passwd. Si no existe comprobación alguna es posible que el programa escriba sobre el fichero de passwords e incluso posteriormente lo borre dejando el sistema en un grave compromiso de seguridad.
La solución de estos problemas es usar la función de la librería estandar de C "tmpfile" que nos dara un path de fichero único. Del mismo modo /tmp no debería de estar asociado a la partición raiz si no tener una propia eliminando estos problemas.
Un caballo de troya o troyano es un programa cuya ejecución permite dejar algún tipo de vulnerabilidad en el sistema. Habitualmente son camuflados en programas inofensivos, pero sus resultados pueden ser debastadores. Habitualmente se asocian los troyanos con maliciosos programas que usualmente borraban o formateaban los datos del incauto "ejecutante", algún tipo de troyanos que existían en la epoca de MS-DOS eran por ejemplo las denominadas "bombas ansi" que camufladas en un artístico ANSI, reprogramaban las pulsaciones de alguna tecla para producir por ejemplo un formateo sin confirmación del disco duro
En sistemas de tipo *nix las cosas cambian, si se produce un borrado de datos, unicamente serán los datos del usuario que lo ejecute. Sin embargo, es importante extremar las medidas cuando ejecutamos programas como super usuario. Será importante confirmar las fuentes de donde han salido los programas a ejecutar. Muchos de estos programas no están destinados a "exterminar" nuestros datos del disco duro si no a producir vulnerabilidades que permitan el libre acceso al sistema.
Es importante validar de alguna manera le procedencia de los programas usados, si es codigo que no pertenece a una distribución es muy interesante revisar el mismo o confirmar el site de donde lo hemos obtenido. Veremos adelante que con la mayoria de las distribuciones estandar para linux ( Suse, Debian, Red Hat ), se proveen métodos para confirmar a ciencia cierta la procedencia y correción del codigo del paquete en cuestión mediante cheksums y firmas criptográficas.
Practicamente todas las distribuciones ( por lo menos las más utilizadas ) tienen métodos de validar si el software que nosotros pensamos que estamos bajando es realmente el que creemos y que no ha sido modificado de manera maliciosa.
Es importante también asegurarnos de donde estamos obteniendo estos paquetes es decir validar la fuente de donde bajamos los paquetes que van a ser instalados en nuestros sistemas.
En las distribuciones el control de seguridad es incorporado en la estructura de paquetes con la que viene cada distribución. Vamos a analizar que métodos acompañan a los tipos de paquetes más comunmente usados para validar su seguridad.
Los paquetes .deb son paquetes que trae la distribución debian