POSIX: System-V Executable and Linkeable Format (ELF) and the Linux ABI

ELF son las siglas en inglés de Executable and Linkeable Format, y es el formato de archivo utilizado por los file objects (.o), binarios, librerías y coredumps en Linux y en Unix en general.
El principio de todo proceso, define al mismo como un archivo en un dispositivo de almacenamiento, que una vez compilado y al ser ejecutado, es cargado en memoria para que el scheduler (mediante el sistema operativo), le asigne tiempo de CPU y recursos a fin de poder ejecutar las rutinas definidas en el.
Este archivo, ya convertido en binario, se encuentra escrito en algunos de los cientos lenguajes de programación que existen actualmente, por ejemplo ANSI C o Fortran. Cuando fue compilado, el compilador en un momento determinado ejecuto el linker, y definió en un header todas aquellas librerías que el programa necesita para poder ejecutarse y que estás les provean aquellas funciones y procedimientos que utilice.
Un binario, puede ser compilado de dos formas, una es estática y la otra dinámica. Compilar un binario de manera estática (parámetro -Bstatic en gcc(2)), significa que se incluirán en el mismo binario todas aquellas librerías que el programa requiera. Por su parte, la principal idea de las librerías compartidas, es tener una sola copia de las mismas instaladas en el sistema operativo y que todo aquel programa que las necesite, haga uso de ellas, y las cargue en memoria para ejecución, en segmentos que pueden ser mapeados de manera privada para el proceso, o compartido entre varios procesos/threads.

Los procesos en Unix, nacen de alguna de las variantes de la syscall fork(2). fork(2), bifurca el proceso padre en una nueva imagen del proceso (una nueva entrada en la estructura proc_t), y mediante exec(2) desplaza esta imagen para crear el mapeo y la estructuras en memoria para el nuevo proceso ejecutado.
Una vez realizado el exec del proceso, y si este está compilado de manera dinámica, en invocado el runtime linker, en este caso ld.so.1,

OpenBSD: Enabling serial console for KVM/libvirt utilization

Tengo un OpenBSD 5.0 con el que estoy realizando una serie de pruebas en una máquina virtual sobre KVM en CentOS 6. KVM en conjunto con libvirt, provee una serie de herramientas para administrar el host virtualizado, una de ella es virt-manager, una herramienta escrita utilizando GTK que obviamente necesita tener X ejecutándose. La otra es virsh, una CLI para administración de hosts virtuales.

Virsh tiene la interesante opción de poder attachear una consola virtual, la cual previamente debe estar configurada en el sistema operativo guest. Esto es importante para poder realizar con la VM todo el trabajo que no podemos hacer de manera remota utilizando SSH y así tener que evitar abrir virt-manager cada vez que tengamos que agregar algún parámetro al booteo, por ejemplo.

Cabe destacar que esta configuración no solo aplica a hosts virtuales, sino también a hosts físicos que tienen la posibilidad o se conectan mediante consola serie. Los pasos para realizar esto son bastante sencillos:

PF: OS based redirection

Supongamos que tenemos en nuestra red dos servidores web, a uno solo pueden entrar los clientes que corran Windows, a los otros los que usan GNU/Linux. ¿Es posible hacer esto de alguna manera sencilla?, la respuesta es si!. Utilizando PF, OS Fingerprints y una regla de redirección.

OS Fingerprints es un mecanismo que tiene PF para determinar el sistema operativo que esta utilizando un host en concreto que pasa por el firewall, lo hace mediante la examinación de algunos campos del header del paquete, como por ejemplo el TTL, y acorde a lo establecido en el archivo /etc/pf.os determina el sistema operativo al que corresponde el paquete.

Unix: Stateful firewalls vs. Non-Stateful firewalls

Hace unos días tuve una interesante discusión en Twitter sobre las ventajas de utilizar como firewall Packet Filter contra Netfilter (IPTables). Cabe destacar que tengo mas conocimientos de PF que de IPTables, por lo cual conozco más las ventajas prácticas del primero que del último.

En teoría de firewalls, encontramos los denominados stateful firewalls, son firewalls que actúan en layer 3 del modelo OSI/ISO (network) donde su punto fuerte es el poder de inspeccionar estados, y saber si los mismos corresponden a una conexión ya existente o no. Esto es posible lograrlo en Linux mediante connectrion tracking utilizando los módulos conntrack, y  así mantener un record de los estados existentes en el sistema operativo.

Tanto Packet Filter como IP Filter utilizan una estructura denominada tabla de estados (o status table), para mantener dicha información. Si un paquete IP ingresa al firewall, se va a buscar mediante una previa inspección del header si el mismo forma parte de una conexión ya existente, y si esto es cierto no se van a inspeccionar reglas de filtrado, sino que el paquete va a pasar directamente. Si un paquete llega por primera vez al firewall, el mismo si matchea con alguna regla, entonces va a crear una entrada en la tabla de estados del firewall, y ya, mientras la conexión siga viva no va a pasar por dicha inspección de reglas.

Linux: Determine if a program is using TCPWrappers

TCP Wrappers es un sistema de ACL's basado en hosts y redes, multiplataforma; Que permite o deniega la acceso a un demonio en un sistema a ciertos hosts o redes, Su configuración se realiza editando los archivos /etc/hosts.allow y /etc/hosts.deny mediante el host o las redes que queremos permitir o denegar y las claves ALL, LOCAL, UNKNOW, KNOW y PARANOID.


Que un demonio utilice TCP Wrappers significa que el mismo fue compilado y linkeado contra libwrap.so y podemos determinarlo simplemente haciendo uso de ldd. Por ejemplo, podemos ver que SSH utiliza TCP Wrappers:

# ldd $(which sshd) | grep libwrap
 libwrap.so.0 => /lib64/libwrap.so.0 (0x00002aae2628b000)