La Falacia de la Barba Verde

Desde hace casi tres años uso Gentoo GNU/Linux como distribución de escritorio. Gentoo goza de una excelente documentación y de un aún mejor sistema de paquetería en lo que a organización se refiere.

Durante todo este tiempo la pega que le achaco es que requiere tiempo.

La idea de Gentoo es construir el sistema desde cero, lo cual requiere cierto nivel de conocimientos y tiempo y paciencia disponibles, pero a cambio da la posibilidad de aprender muchísimo acerca de los internals del sistema.

Aunque en teoría uno no tiene por qué compilar absolutamente todo el sistema sino que uno se puede bajar los binarios ya precompilados, yo aún no he conseguido encontrar binarios para mi arquitectura (Prescott) por lo que me veo obligado a compilar todo paquete que quiero instalar. Compilar emacs, vi, gedit, … bueno, si lo tienes que hacer unas cuántas veces aburre, pero hay paquetes como xorg-server, gcc, gnome y sus dependencias que tranquilamente pueden tirarse más de media hora compilando, y esto en cada actualización del sistema se hace un tanto insoportable.

Si el año pasado me cargué la distribución instalando GNU/Hurd (y trabajando como root cuando no debía acabé sobreescribiendo la libc de gentoo con la libc de Bee GNU/Hurd) este año fue al actualizar portage (el gestor de paquetes de gentoo, como el apt-get o el dpkg de debian) al 2006.1 cuando la toolchain volvió a hacer chof! y desde entonces conté sin la posibilidad de poder compilar programa alguno, y por tanto de instalar nada.

Ha sido ahora en estas vacaciones, tras comprarme un disco duro nuevo, cuando me he decidido a hacer las copias de seguridad esas que siempre hay que hacer y que nunca se hacen y tras ello arramplar con todo lo que había instalado y partir de cero.

Los objetivos eran tener instalado OpenBSD, Solaris 10 (del cuál recibí los DVDs gratuitos que enviaban si los pedías) y varias distribuciones de Linux: una para trabajar habitualmente (Gentoo), otra por si todo falla (Debian) y otras por probar. Respecto a Windows: en la facultad tan sólo voy a verme obligado a usar windows durante este cuatrimestre y un mes el segundo cuatrimestre del año que viene (y para eso puedo emplear otro ordenador o un emulador), no acostumbro a jugar con el ordenador, y además es una fuente de problemas, incompatibilidades, virus y otros disgustos, así que finalmente he decidido no instalarlo. Llevo 3 años sin usar windows, y salvo cuando los colegas me piden que les arregle el ordenador que ya no me acuerdo ni dónde está el panel de control, no tengo mayor problema en apañármelas a diario sin windows.

OpenBSD desde hace ya tiempo me llamaba la atención por estar enfocado a la seguridad y tener ese sistema de desarrollo que a veces he echado en falta en Linux. Quise probarlo y tras comprar el CD de la versión 3.9 al final he conseguido instalarlo. Hay que decir que el fdisk que trae es difícil de usar, de hecho primero instalé Debian en un segundo disco duro y desde allí particioné el primer disco con el fdisk de debian, que es bien cómodo. Salvado ese escollo la instalación fue sencilla y apenás duró diez minutos, esencialmente porque no instala casi ningún programa. Una vez acabada y haciendo uso del sistema de ports (que por cierto, la base de datos de ports no la encontré en el CD) ya instalé más aplicaciones como p.ej. GNU screen. No es un sistema agradable a los sentidos, ni creo que lo pretenda, más bien es un sistema espartano, orientado a la seguridad y a cumplir ese objetivo de ser seguro, no el de ser amigable.

Solaris es software no libre, pero es un Unix bastante usado en servidores y sólo por eso merece conocerse un poquito, al menos probarlo, y ya que me enviaban una copia a casa gratuitamente… (llegaron tres DVDs: Solaris 10 x86, Solaris 10 SPARC y las Developer Tools). Parece ser que no reconoce los discos SATA (tuve un problema similar hace 2 años con FreeBSD) así que trataré de apañar un disco IDE de al menos 20 gb., ya que Solaris es caprichosín, al menos en cuanto a espacio.

Debian: probablemente la mejor distribución de Linux. El sistema de paquetería es cómodo como el de Gentoo (inspirado en los ports de BSD). Fácil de instalar, apenas da problemas. Estrictos con las licencias libres (iceweasel, apache1.3, etc.). Tiene una gran comunidad de usuarios (probablemente sea la distribución de Linux con mayor comunidad), aunque no está tan bien documentada como Gentoo. Creo que daba ciertos problemas el instalador con mis discos SATA, pero yendo sobre aviso lo arranqué sin problemas. Dado que por cuestiones de licencias en Debian no está disponible el firefox original, sino el ice-weasel, que no es capaz de leer los ficheros de contraseñas o el historial del firefox que usaba antes, he decidido instalar firefox por mi cuenta, desde la web de mozilla y prescindir del soporte de Debian en este aspecto, e ídem para thunderbird/ice-dove.

Ubuntu: Traté también de instalar Ubuntu, pero tras bajarme y quemar el CD de instalación me encuentro con que en el particionado, si / no está asignado a una partición primaria para el instalador de Ubuntu 6.10 es como si no se le hubiera asignado partición a /, y en consecuencia se queja y no me deja instalar. Esperemos que Feisty Fawn, que sale en 10 días, resuelva este despiste de programador. Pese a esto la interfaz gráfica de Ubuntu está muy cuidada (aunque Gnome 2.16 en general me ha sorprendido muy gratamente).

OpenSUSE es lo que toca en la facultad cuando toca. Si ocurre el milagro de que allí haya algo que no sea Windows instalado, entonces ese algo es OpenSUSE (a excepción de los Macs con su OS X). Antes estuvo Kubuntu (o alguna otra ubuntu) y antes aún creo que Debian. Lo que me maravillaba de OpenSUSE es la interfaz gráfica, que pese a ser KDE es muy atractiva, incluso antes de arrancar las X, en el inicio, mediante el framebuffer se obtiene una pantalla de arranque realmente elegante. Intenté instalarlo, pero a falta de los cinco CDs o el DVD que no pensaba bajármelos ni loco, me bajé el CD de instalación, e iniciándo esta me encuentro con un simpático cuadro de diálogo que me pide la dirección IP de un mirror de SUSE. Tras reiniciar en Debian y buscarle un mirror (y resolver el FQDN, no siendo que efectivamente quisiera la IP), vuelvo a arrancar la instalación y le meto la susodicha IP y a continuación la ruta dentro del servidor hacia el repositorio de SUSE. En proceso de bajarse root.gz, un fichero de 70 megas que debía contener lo esencial para ir instalando procedo a dormitar la siesta. Y volviendo media hora después pensando en que estaría esperando mis órdenes me encuentro con que se ha quedado atascado a los 20 megas. Así que ahí se quedó. Algún día que me encuentre con ánimo para bajarme el DVD de instalación por mi canuto ADSL lo haré y lo instalaré. Algún día. Mientras tanto, si esto lo lee algún programador de SUSE, que por favor, se le ocurra poner cuanto menos una lista de mirrors en el programa de instalación, y a ser posible que use el servidor de nombres que le devuelve el servidor DHCP, que no me pida la IP.

Otro fallo que le he visto a SUSE cuando hace años la usaba (versión 6.5, 7.2, etc.) es el sistema de paquetes, que no es en absoluto comparable a lo que estoy acostumbrado a ver en otras distribuciones. Es realmente muy incómodo.

Y finalmente Gentoo

Hoy es el quinto día de la instalación :D. Tras las primeras compilaciones, reajustando el USE y recompilando, y buscando errores en el Google, he conseguido mis Xorg corriendo con Beryl (que es flipante, a todo esto). He conseguido tener también un fallo con libexpat, ya que en un inicio estaba la versión 1.95.8 instalada y al actualizar el sistema ha pasado a la 2.0.0, con el consecuente fallo de que los programas enlazados a la 1.95.8 (evince, aMule, etc.) no la encontraban y cascaban. Con un revdep-rebuild (del paquete gentoolkit) parece que poco a poco todos los programas que la enlazaban van recompilándose y reenlazándose de nuevo. Mientras tanto en el proceso alguno se queja de las USE flags con los que alguna que otra dependencia ha sido compilada y toca cambiar las USE flags, recompilar la dependencia y volver a empezar el revdep-rebuild (desde el principio). Por lo menos sólo tiene que compilar 52 paquetes (entre ellos gcc y evolution), al menos el open-office no lo tiene que tocar hasta que no lo instale.

Por cierto, para gentoo usé la guía de instalación rápida. Y rápida es, lo que pasa es que es Gentoo. Y si te pones a hacer virguerías como instalar beryl y luego te pasas a ~x86 y te surgen problemillas pues ya te tiras un rato, y si además andas instalando programas de uso obligatorio (gnome y sus dependencias, el kernel, etc.) al final… lo dicho: cinco días. Pero ya casi casi está del todo.

Como colofón, pongo aquí mi /boot/grub/menu-lst, por si a alguien le sirve de ayuda, especialmente en lo que a arrancar OpenBSD 3.9 se refiere:

default 0
timeout 30
splashimage = (hd0,0)/grub/splash.xpm.gz

#Arrancar Gentoo. Kernel instalado en /dev/sda1 (/boot), el / está en /dev/sda6
title = Gentoo Linux 2.6.20-gentoo-r5 20070408
root (hd0,0)
kernel /bzImage-2.6.20-gentoo-r5.20070408 root=/dev/sda6 real_root=/dev/sda6 vmalloc=300M

#Open está en /dev/sda3, esto es (hd0,2)
title = OpenBSD 3.9
root (hd0,2)
makeactive
chainloader +1

#Debian: kernel y la initrd en /dev/sdb1, sistema (/) en /dev/sda3
title = Debian GNU/Linux 4.0 2.6.18 … 20070406
root (hd1,0)
kernel /vmlinuz-2.6.18-4-686 root=/dev/sdb3 ro bootkbd=es noapic nolapic
initrd /initrd.img-2.6.18-4-686

Si hace unos días comentaba acerca de los atributos de los ficheros en la implementación de OpenBSD del Unix File System (o Fast File System), ahora mismo estaba viendo su equivalente en ext2, el que fuera hasta hace un par de años sistema de ficheros por defecto de Linux, sucedido por ext3 (que es compatible hacia atrás con ext2) y que dentro de poco será sucedido por ext4 (que de momento y por lo general sí es compatible con ext3).

Los dos comandos que permiten trabajar con los atributos de un fichero son lsattr y chattr, respectivamente para mostrarlos o cambiarlos. Ambos forman parte del paquete e2fsprogs.

Los susodichos atributos son 15, a saber:

• ‘A’ evita que se modifique el campo atime (accesed time, última vez que fue accedido un fichero) del fichero cada vez que se accede a él. Puede reducir la carga de I/O del sistema.
• ‘a’ indica que el fichero sólo se puede abrir para añadir si se abre para escritura. Tan sólo root o un proceso con el flag CAP_LINUX_INMUTABLE pueden activar o desactivar esta opción.
• ‘c’ indica que el fichero se guardará comprimido. Por supuesto, la compresión será transparente al acceso al fichero. A la hora de acceder uno no tiene que preocuparse si el fichero está comprimido o no, eso es cosa del kernel. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
• ‘D’ implica actualizaciones síncronas de los directorios cada vez que son accedidos. Sólo es útil a partir de la rama 2.6.
• ‘d’ excluye al fichero de los programas seleccionados por dump para ser copiados.
• ‘E’ indica que un fichero tiene un error de compresión (los ficheros de la ‘c’). Es usado por los compresores en etapa experimental, y tan sólo puede ser visualizado mediante lsattr, no puede ser cambiado mediante chattr.
• ‘i’ impide que se modifique el fichero o que se cree un enlace hacia él, que se elimine o se renombre. Sólo root o procesos CAP_LINUX_INMUTABLE pueden cambiar este flag.
• ‘j’ hace que todos el fichero sea escrito primero en el journal de ext3 y luego en disco en caso de que el sistema de ficheros esté montado con los modos data=ordered o con data=writeback (con data=journal siempre se hace esto). Sólo root o procesos con la capability CAP_SYS_RESOURCE pueden trastear con esto. Sólo tiene sentido con ext3, no con ext2.
• ‘s’ se asegura de que al borrar un fichero, todos sus bloques son rellenados con ceros en el disco. Esta forma de borrado segura presenta varias limitaciones. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
• ‘S’ actualiza los ficheros de forma síncrona. Similar a la opción sync de mount.
• ‘T’ manda un directorio a la cima de la jerarquía de directorios. Está relacionado con el asignador de bloques de Orlov presente en la rama 2.6 del kernel desde que se portó la idea de BSD.
• ‘t’ evita el tail-merging. A excepción de una serie de parches ext3 no cuenta con soporte para tail-merging.
• ‘u’ guarda el contenido de un fichero cuando éste es borrado, permitiendo así la recuperación del fichero. En las versiones actuales del kernel no está implementado, pero se prevee para versiones futuras.
• ‘X’, al igual que ‘E’ es usado por los compresores experimentales e indica (y sólo indica, por que no es modificable) que el fichero pese a estar comprimido puede ser accedido directamente.
• ‘Z’ es similar al anterior, salvo porque indica que el fichero comprimido está sucio.

Desde luego, la variedad de opciones que presentan estos atributos es mayor que la del UFS de OpenBSD, y no sólo mayor si no también diferente. Lástima que Linux no cuente con los Secure Levels de OpenBSD porque a nivel de seguridad (más que de usabilidad) le confieren gran potencia.

Es el libro que más me han recomendado como introducción a OpenBSD, y en mi caso a los Unix *BSD en general.

Su autor es Michael W. Lucas, autor de una columna llamada Big Scary Daemons en el O’Reilly Report. Autor también de Absolute BSD (publicado también por No Starch Press) y con amplia experiencia en BSD y como administrador de sistemas y redes en general.

Son unas 450 páginas sin contar el índice alfabético, que tratan de explorar a nivel introductorio las capacidades de OpenBSD, y dar una formación básica de cómo instalar el sistema en diferentes entornos y configurarlo para diferentes tareas.

Sin haberlo instalado aún fuera de un emulador y apenas sin haberlo probado este libro me ha permitido ver la enorme potencia que alberga OpenBSD. Se habla ya en los últimos tres capítulos del PF (packet filter) , el firewall de OpenBSD. Enormemente configurable (y mucho más cómodo de hacer, a diferencia de las iptables de Linux) y con unas capacidades que nada tienen que envidiar a las de los kernels de Linux. Es más, cuenta con ciertas opciones de las que Linux carece.

El protocolo TCP (v4 al menos, v6 lo desconozco) mantiene un intercambio de números de secuencia (ISNs) y de reconocimiento en cada uno de los paquetes que se envía dentro de un flujo de datos. La finalidad de este intercambio es dificultar el robo de conexiones o la suplantación de identidad de cliente o servidor. Para ofrecer de verdad seguridad las pilas TCP de los diferentes sistemas debe generar los ISNs de forma aleatoria mediante generadores de números seudoaleatorios (PRNG).

Es de sobra conocido que hay algunos dispositivos tontos (impresoras o scanners en red, etc.) que o bien usan un número constante como ISN o bien a la hora de modificarlo simplemente le suman una constante, de forma que la aleatoriedad es más bien nula. En cualquier caso, el análisis de éstas secuencias de número provenientes de una máquina dada permite saber qué tipo de PRNG ha sido usado, y por tanto qué tipo de máquina, sistema operativo y a veces incluso versión del SO ha entrado en juego. Ésta técnica de análisis es una de las más empleadas a la hora de hacer OS-fingerprinting ([1], [2, 0x0F] y [3]) por programas del estilo de nmap.

Windows al igual que Solaris o Linux o BSD usa números seudoaleatorios, el problema es que el generador de número seudoaleatorios (PRNG) es bastante pobre, por lo que a parte de averiguar que dentro de nuestra intranet hay un servidor Windows, también resta dificultad a la hora de hacer spoofing, p.ej.

PF ofrece la posibilidad, a la hora de hacer NAT/Masquerading con un router con OpenBSD, de reemplazar los ISNs de los paquetes TCP que provienen de la intranet, de forma que un sistema en el exterior pese a analizar las secuencias de ISNs no sea capaz de determinar el sistema operativo real. En su lugar lo que estarán analizando los atacantes son las secuencias generadas por el router, y por tanto por el PRNG de OpenBSD, que no sólo no es el correspondiente al servidor que tenemos en la intranet, sino que además es más seguro que el de Windows. Hasta donde yo sé Linux hoy en día no ofrece esta posibilidad.

OpenBSD es un sistema operativo orientado principalmente a la seguridad. Ya en su página principal presumen de no haber tenido más que dos agujeros de seguridad remotos en la instalación por defecto en los últimos diez años (a costa de venir con más bien poquitos servicios activados por defecto, se discutía esto en Barrapunto hace poco).

Y con tal finalidad cuenta con diverso número de medidas como son el systrace, el propolice, W^X, las pilas no ejecutables y los securelevels. Algunas de ellas compartidas con GNU/Linux.

El systrace es un sistema de políticas de interceptación de llamadas al sistema operativo. Permite interceptar todas las llamadas por parte de un proceso dado a una función determinada, y una vez interceptadas, obrar en consecuencia. Si un día se descubre que el demonio rinetd que tenemos corriendo cuenta con una vulnerabilidad que a un atacante le permite leer el fichero /etc/shadow, digamos con fope(“/etc/shadow”,”r”);, systrace nos permitiría definir una política tal que todas las llamadas de rinetd a fopen con ese argumento fallen y devuelvan NULL en vez de abrir el fichero y devolver un FILE * válido que permita leerlo. Serviría como parche hasta que se publique una nueva versión de rinetd sin ese fallo.

El propolice permite asegurarse de que la dirección de retorno de una función no ha sido modificada y el W^X se asegura de que ninguna página es ejecutable y escribible a la vez, sino que o lo uno o lo otro.

Y finalmente los securelevels: hay 4, desde el -1 (menos seguro) hasta el 2 (más seguro) , y una vez se pasa de uno menor a otro mayor no se puede bajar, salvo reiniciando la máquina. En cada securelevel se ponen en juego una serie de restricciones por parte del sistema operativo.

En el Unix File System (o Fast File System), que es el sistema de ficheros que emplean los BSDs (y Solaris) los archivos, al menos en OpenBSD, pueden tener una serie de flags activadas. Por defecto ningún fichero trae ninguna activada, pero podemos decidir activa el flag schg (system-level immutable flag) sobre un fichero. Esto impedirá que nadie pueda editar, mover o reemplazar ese fichero si no es quitando el flag antes, y para quitarlo hay que ser root, y además de estar en un securelevel menor que 1. Si estamos en el 1 o en el 2, no tendremos más remedio que reiniciar en el -1 o el 0, cambiar el flag y luego ya reiniciar normalmente y proceder.

Como consideraciones finales decir que OpenBSD soporta también varios tipos de ejecutables, a la vez que los suyos propios, soporta la ABI de Linux p.ej., y también alguna más. Me ha dado la impresión de que el sistema operativo, al menos en lo que respecta al manual, está muy bien documentado, y en mi opinión mucho mejor que Linux.

Hay quién dice que es más rápido que Linux. Yo en un análisis el año pasado vi lo contrario, entre Free, Open y Linux el peor parado en cuanto a velocidad era Open, pero teniendo en cuenta las comprobaciones de seguridad que ofrece frente a los otros no es de extrañar. De todas formas todos estos análisis sobre seguridad hay que cogerlos con pinzas, si es que uno se decide a cogerlos (¿tienen gran utilidad? ¿hay gran diferencia de velocidad? ¿compensa usar algo más rápido y más inseguro?).

Así mismo, el libro está un poquito desfasado ya que es del año 2003 y no creo que haya sido revisado mucho desde entonces. Se nota en ciertos capítulos relativos a la instalación y en que se está refiriendo a OpenBSD 3.2 (en mayo saldrá la 4.1, cada 6 meses sale una nueva). No obstante lo recomiendo para iniciarse con OpenBSD.

Hoy alguien preguntó a la salida de clase acerca del término demonio. ¿Por qué los demonios se llaman demonios? Hace tiempo leí acerca de ello.

Originalmente había una serie de programas en los unix que monitorizaban el sistema permenentemente, estos monitores del sistema se llamaban day-monitors, que al abreviarse quedan como daemons, razón de que alguno lo aproximara a demons, y otros a demonios.

El proceso de llegar a ser un demonio (daemonize) esencialmente consiste en lo que se llama fork off and die, es decir, hacer un fork(). Como sabréis fork() crea un proceso similar al proceso que lo ha llamado, pudiendo llegar a ejectuarse en paralelo uno y otro.

La llamada a fork() puede devolver un entero menor de 0 para indicar error. Algo mayor que cero para indicar que eres el padre (lo que está devolviendo es el PID del hijo), y por tanto ahora vas y cumples con la segunda parte del trato: el die.

En caso de que el fork() te haya devuelvo 0 es que eres el hijo, en cuyo caso ya estás daemonizado, y como tu padre ha muerto (o debería de estar muriéndose), has pasado a ser adoptado por init. Ya puedes hacer tus cositas.

Dicho en cristiano:

#include <stdio.h>

#include <sys/types.h>

#include <unistd.h>

#include <stdlib.h>

int main(int argc, char **argv)

{

pid_t hijo;

hijo=fork();

if(hijo<0) {

perror(“Couldn’t fork off!!”);

exit(EXIT_FAILURE);

}

if(hijo>0) {

printf(“Soy el padre!! tiene el pid %d\n”,hijo);

exit(EXIT_SUCCESS);

}

/*Código del hijo*/

printf(“Soy el niño tonto\n”);

exit(EXIT_SUCCESS);

}

Realmente los demonios no pueden escribir a stdout, usan la consola o un fichero de log, porque la I/O la tienen desasociada (igual que no deberían leer de stdin) .

Una entrada cortita pero nutritiva para vuestra cultura [geek] general. Para los que quieran más y mejor que sepan que la Wikipedia tiene su correspondiente definición con unos enlaces sabrosones.

¿Cómo saber si existe un proceso con un PID determinado? ¿existe algún proceso con el pid 16547?

Se me ocurrieron diferentes formas, algunas poco portables, en otras presentaba dudas, así que pregunté en varias listas de correo.

Y el resultado es este programita en C donde se presentan dos formas programadas (y que funcionan) y comento más o menos cómo funcionan, así como la gente que me ha dado ideas y qué ideas me han dado: existe_pid.c;

Por cierto, gracias a todos los que colaborásteis con este tema.