Pues quieren comparar SELinux que es lo que es con OpenBSD que también es lo que es. Los argumentos son de lo mejorcito:

• Es complejo: Vale, no es fácil, aunque distros como Fedora y RedHat creo que tienen asistentes. ¿Tiene OpenBSD algo tan potente? ¿Hasta dónde llega TrustedBSD? Solo hay que buscar un poco por internet para leer preguntas como Does OpenBSD have something similar to the NSA`s SELinux, RSBAC, PaX stack smashing protection, Grsecurity etc? y leer esta joya de respuesta: OpenBSD has a “secure-by-default” approach with focus on security and code correctness. There`s no need for extra addons like SELinux and grsec kernel patches.
• Insinuan, o me lo parece a mi, que APPArmor es mejor que SELinux cuando APPArmor tiene al menos que yo conozca, limitaciones, como que no permite controlar sockets, o que se referencia a los ficheros por su ruta y no mediante labels en el sistema de ficheros (Como si de una ACL o atributo extendido se tratase). Aquí una comparación de ambos.

Os dejo un artículo que me gusta mucho ya que explica muy bien como funciona PaX (Parte de la suite GRSecurity para Linux, que aunque no tenga nada que ver con SELinux, es un elemento más en la fortificación de un sistemas Linux) y W^X de OpenBSD.

Vamos, que en mi opinión no es solamente qué se usa, sino cómo se usa y como de implementa, y en mi opinión Linux ofrece más herramientas para fortificar el sistema que un sistema OpenBSD y quien no quiera ver más allá de la calidad del código en mi opinión no está haciendo una buena evaluación de todo el rol. OpenBSD todos sabemos que tiene fallos. Pocos, pero ahí están y sus paquetes tambien tienen fallos, y los paquetes no son parte del core, luego no son auditados, luego la misma cagada que comete el devel de determinada aplicación de lo que sea en Linux, puede cometerlo en el paquete de OpenBSD (Si lo incluye, claro, y si tiene esa misma versión). Y digo yo… de que sirve tener un sistema base con un muy buen código si luego tu aplicación que escupe html o correo es vulnerable? Creo que es ahí donde entra PaX, SELinux, RSBAC, etc intentando que la explotación de la vulnerabilidad no sea tan fácil de llevar a cabo…

Esa es mi opinión. Un saludo.

El otro post en un tono, en mi opinión, humorístico, dice que tiene que dejar de lado su necesidad por la cerveza, ya que no puede gastar todo su sueldo en ella, ¡O aún peor! Una hackathon sin ella.

Parece que ha perdido su trabajo por lo que está en el paro. Necesita un nuevo trabajo de 8 horas para tener los suficientes fondos para continuar con el proyecto (OpenBSD).

En este momento he llegado a la confusión total, y es donde necesito aclaraciones. Theo anuncia de forma no oficial un 0 day en OpenSSH. Si leéis el mensaje es una broma, pero luego dice que tiene que ponerse a trabajar, que venderá todo el hardware que tiene para comprarse un portátil nuevo, ya que OpenBSD soportará solamente la arquitectura x86. Esto es alarmante, o podemos tomarlo a broma, pero es en el último post cuando confirma la venta del hardware (Máquinas Sun principalmente) y la compra de un nuevo portátil económico pero nuevo, cuya tarjeta wifi no funciona bajo OpenBSD, y que, aunque esté en contra de ellos, ha recurrido a un blob para hacerla funcionar, ya que el driver de Windows soporta WPA2, y lo utilizará con ndiskwrapper. La tarjeta ethernet funciona, pero no es lo que es esperaba, además necesita la wifi para su trabajo.

¿Es confuso verdad? Un tío tan crítico con los drivers cerrados como Theo, echando mano de un blob (O eso he entendido), el pobre sin curro y por lo tanto sin dinero, y sin poder dedicarle dinero al proyecto. La verdad que es jodido, o quizá lo he entendido yo mal, así que, si no os fiáis de mi, podéis leer su blog, que es muy interesante, en gran parte para conocer qué piensa Theo. Por ejemplo, cambiar Sendmail por Qmail, pero ni de coña por Postfix o Exim, por su licencia (WTF!)

Una vez arrancamos NUT al completo, ejecutamos knutclient y añadimos un SAI, Su alias, su host y su nombre, además de usuario y contraseña. Luego configuramos a nuestro gusto para dejarlo como nrktk en su captura… o a vuestro gusto. Bueno, yo, al igual que él, pienso instalar 2 SAIs nuevo que me tiene que traer en serie. Uno es un Zaapa de 1000 VA, tonto, como una batería no monitorizable. El otro será un APC de 700 VA, que NUT parece soportar además de tener su propio daemon. La idea es colgar el/los servidores y el firewall, así como el AP y los switches y modems de ambos (1000 y 700 VA) y mi equipo de mi viejo Energy System de 1200 VA.

Como NUT es fabuloso y soporta monitorización por red (Con ACLs, usuarios contraseñas…) y además está disponible en casi todo SO *NIX que os podáis imaginar, puedo instalar los SAIs en el equipo que yo quiera (Tampoco tengo muchas opciones) y monitorizarlo desde el equipo que quiera (¿Desde el mío?). Además cuando mande al sistema apagarse puede retransmitir a sus esclavos que también se apaguen. Como veis, todo son ventajas . Lo haré y lo documentaré, aunque quizá se me adelante nrktk .

Bueno, la aplicación está diseñada para KDE (QT3) y se integra muy bien en el systray. Personalmente me gusta mucho, así que podéis animaros a probarla.

Es una herramienta que hará paquetes binarios de los parches de seguridad de OpenBSD de forma casi automática. Las ventajas saltan a la vista cuando tenemos más de una máquina con este Sistema Operativo instalado y queremos ahorrarnos los ciclos de CPU. Como explica en su web, su uso es sencillo y además crea una lista de los ficheros modificados.

En mi opinión está bien, pero por otro lado, no metería algo externo al sistema base para algo tan crítico como las actualizaciones de seguridad. Prefiero el sistema de toda la vida.

• Actualizar el sistema según indica su manual.
• Instalación limpia.

He optado por la instalación limpia por dos razones:

• El método usado para actualizar es, en mi opinión, algo lo sobreescribimos y venga
• Casi todo lo que uso está incluido en el sistema base, excepto Squid. Las configuraciones las guardo mediante scp.

¿Y qué gano con esto?
Pues tengo la última versión del sistema (RELEASE) la cual hay que actualizar a el PATCH BRANCH 3.9 (STABLE) pues desde que salió hasta ahora el sistema base tiene tres vulnerabilidades. Dos referentes a Sendmail y una a XOrg. Si esta máquina estuviese en un entorno de producción no sería viable la reinstalación probablemente, pero como mis configuraciones son pocas puedo apañarme aún y guardarlas.

La verdad hecho de menos 2 cosas en OpenBSD.

• Un RSS para recibir los avisos de vulnerabilidades con un lector de feeds, sin recurrir a listas de correo o visitar la web.
• Un tiempo de vida de la versión mayor.

Mientras he escrito esto he estado actualizando el sistema desde el CD, osea, el método que no iba a usar, pero… ¿Quién dijo que no lo iba a probar?
Digamos que se parece a la instalación. Tras escoger el tipo de terminal que usaremos y el mapa de teclado, nos pide confirmación para actualizar.
Acto seguido nos manda escoger el disco duro que usaremos (wd0), así como el sistema de ficheros raíz (wd0a).
Es ahora cuando nos permite configurar una interfaz de red con la configuración del sistema instalado o asignársela nosotros a mano. Es útil si vamos a hacer una actualización por red.
A continuación nos pregunta si queremos editar el fstab con ed.
Cuando le contestemos que no, como fue mi caso, procederá a comprobar con fsck la correcta integradad de las particiones.

Esta nueva fase de la actualización se parece a la instalación ya que pide el origen de los datos, cuya opción por defecto es CD. A continuación la ruta que por defecto es 3.9/i386 pero como no es una ISO oficial y la hice yo, tendrá que ser i386 a secas.
Esto ya es familiar, nos manda escoger paquetes a actualizar. Yo uso ese sistema por defecto excluyendo el paquete game39.tgz por lo que escribo -game39.tgz, doy intro, escribo done y finalizo.

Nos pide la última confirmación para actualizar y procede a copiar el kernel y extraer los paquetes.

Cuando finalice nos pedirá de nuevo una localización de los ficheros, pero como hemos terminado escribimos done, procederá a crear los ficheros de dispositivo y nos devolverá al prompt con un mensaje felicitándonos por la correcta actualización.

Cuando arranquemos continuaremos con esta guía de pasos finales.

Para actualizar nuestro nuevo sistema podemos leer este manual adaptándolo a la versión 3.9 que supongo no habrá cambiado.

Está en ello, y si os digo la verdad, por no particionar de nuevo y demás lo dejo así.

Quien sabe, quizá pida unas camisetas como ésta y ésta otra.
Necesitan ayuda y los que lo usamos deberíamos hacer lo posible por que tire para delante, aunque claro está que quienes más deberían preocuparse son, a quienes cuyo dinero y tiempo afecta este proyecto.

Agur

Volviendo al tema del Access Point…
¿Alguien sabría decirme? ¿Experiencias positivas o negativas?

Ahora sí, buenas noches.

Agur

Hace unos meses, cuando vi el proyecto OpenSuSE, decidí probar Gentoo. Aquí tienes 2 ramas, la estable y la inestable. Yo uso la estable y tengo paquetes de la inestable, como por ejemplo en KDE, interfaces gráficas, etc… También cabe destacar los GLSA (Gentoo Linux Security Advisories), que simplemente, si hay una versión vulnerable la actualiza a una superior. Es lo único que no me gusta del todo si la usase como servidor, ya que estoy acostumbrado a Debian Sarge y su política de actualizaciones.

Y a lo que iba, OpenBSD. OpenBSD no distribuye ISO de sus CD”s, así que tendremos que hacerla nosotros mismos. Una vez instalada tenemos una OpenBSD 3.8-RELEASE, que es la que tiene los CD”s. Pero eso no es una rama, no se actualiza, se liberó y punto. Éste es el momento en el que tenemos que elegir que rama escoger, si la -STABLE o la -CURRENT. Si queremos un sistema en producción, claramente actualizaremos a -STABLE.

Los fallos de seguridad del sistema base los tenéis aquí y los de paquetes de la rama STABLE aquí.

Como veis hay 3 fallos de seguridad. Hoy he encontrado la forma más cómoda (en mi opinión) de actualizar el sistema base.

Actualizamos las fuentes del sistema al patch brach OPENBSD_3_8:

*default host=rt.fm
*default base=/var
*default prefix=/usr
*default release=cvs
*default delete compress

OpenBSD-src tag=OPENBSD_3_8

Eso lo guardamos en, por ejemplo, ~/supfile.

Ahora montamos el CD y extraemos el paquete src.tar.gz a /usr/src y sys.tar.gz a /usr/src/sys. Una vez descomprimido ejecutaremos:

cvsup -g -L 2 ~/supfile

Nota: La ooción “-L 2″ es el nivel de debug del proceso.

Cuando termine tendremos un /usr/src actualizado.

Aún no hemos actualizado a STABLE, así que con todo ya preparado seguimos la guía. Compilamos nuevo kernel, lo cambiamos, reiniciamos con el nuevo y luego recompilamos binarios.

Nota: A la hora de compilar es imprescindible tener instalado el paquete misc.tgz que viene en el CD. Si no es así, lo descomprimís en el raíz.

Ahora tenemos la OpenBSD 3.8-STABLE. Revisamos que los paquetes estén en su última versión disponible y lo ponemos a funcionar de lo que nos dé la gana, supongamos que de cortafuegos.

Pero claro, no existe nada perfecto, y como hace unos días, un bug en la función scp de SSH. Ahora nos planteamos como actualizar…

• Ejecutar de nuevo cvsup -g -L 2 ~/supfile y recompilar todos los binarios del sistema y si es el kernel, el kernel
• O la otra opción, que como no hay muchos fallos, no será caótico. La alternativa es bajarse los .patch y aplicarlos

Yo he optado por la segunda opción:

wget patch
less 005_ssh.patch

(salida)
Apply by doing:
cd /usr/src
patch -p0 > 005_ssh.patch

And then rebuild and install ssh:
cd usr.bin/ssh
make obj
make
make install

Pues esas son las instrucciones, bien claras.

La primera opción hubiese sido una muñonada, recompilar todo el sistema a lo tonto, para que por ejemplo luego casque algo. De este modo lo único que tenemos que hacer es estar pendientes de los fallos de seguridad que aparecen, parchear el código fuente y fijarnos a qué afecta la vulnerabilidad, si a algún binario del sistema base o solo al kernel, y compilar.

Una vez recompilado en nuestro ejemplo SSH, mataremos sshd y volveremos a ejecutarlo. Si estamos en remoto lo más probable es que perdamos la conexión con el host. Se me ocurre una idea, que es programar un trabajo que se ejecute en 2 minutos, por ejemplo.

Otra cosa que me he pasado por alto es que Apache y Bien9, por ejemplo, forman parte del sistema base, es decir, si sale una vulnerabilidad tendremos que recompilarlo como hicimos ahora con ssh. Las versiones que trae OpenBSD son viejas, pero eso no es malo si cumple con tus necesidades, ya que al ser más viejas están más auditadas (Recordad que el sistema base es auditado, pero los paquetes es cosa del desarrollador no del equipo de OpenBSD). ¿Qué quiero decir con esto? Que mejor usar en lo posible lo que el sistema base nos brinda, si no es posible, los paquetes, y sino, los ports. También podemos recurrir al código fuente oficial del software en cuestión, pero bueno.

Si usáis ports, al igual que lo demás, tendréis que actualizarlos, para ello basta con añadir la linea:

OpenBSD-ports tag=OPENBSD_3_8

Entonces creamos el directorio /usr/ports (Porque no estoy seguro de si lo crea) y actualizamos.

Todo este código fuente y post ocupa espacio, así que una buena idea sería volcarlo mediante NFS en otra máquina con más capacidad de almacenamiento.

Con esto doy por concluido, cuando tenga un rato lo pondré en mi web.

Agur

En 1969 la empresa AT&T encargo a Ken Thompson y Dennis Ritchie reducir el sistema operativo MULTICS para portarlo a los equipos más pequeños que la NASA utilizaba en sus misiones espaciales. A finales de ese año presentaron un sistema al que llamaron UNICS (UNiplexed Information and Computing Service) un ‘emasculated Multics’. Nadie sabe en que momento UNICS paso a ser Unix, pero según cuenta la layenda urbana, una secretaria no supo como escribir lo que le dictaban y escribió Unix y el nombre así se quedo.
El profesor Bob Fabry de la universidad de California en Berkely fue uno de los primeros interesados en conocer Unix y pidió una copia a la Universidad de Purdue, donde Thompson y Ritchie trabajaban. Sin embargo el mainframe de Berkeley poseía unos controladores de disco duales que Thompson no había previsto y trabajando junto con el departamento de matemáticas de Berkeley agregaron el soporte que faltaba. Esto fue el inicio de un intenso periodo de colaboración entre Berkeley y Bell Labs (subsidiaria de AT&T) al grado que Thompson tomó un año sabático en California para seguir desarrollando a Unix. Bajo su guía varios profesores y estudiantes de Berkeley realizaron cientos de mejoras y extensiones al kernel de Unix.
La segunda versión de Unix apareció en 1972. Por esas mismas fechas Ritchie reescribió el lenguaje B, creando a C. La sexta edición de Unix se libera en 1975, junto al nuevo Bourne Shell. En 1977 el estudiante graduado Bill Joy colocó todas las mejoras hechas en Berkeley y lo llamó “Berkeley Software Distribution.” Al poco tiempo Joy había enviado más de treinta copias de BSD a varias universidades. Las copias incluían al nuevo editor que Joy había creado: vi. Sin embargo, las características de las terminales variaban mucho y Joy decido escribir un pequeño intérprete que dibujaba la pantalla según sus características y así nació termcap. En 1979 se lanzó la séptima edicion de Unix y la tercera de BSD: 3BSD.
Por esos tiempos, el ejército estadunidense estaba preocupado por la escasa interoperatibilidad entre las plataformas que conformaban sus sistemas a través del país. Se pensó diseñar un hardware específico pero luego de pensarlo otra vez decidieron unir sus equipos a nivel de software, Unix fue el elegido para ello debido a su portabiliad. Los encargados del proyecto se pusieron en contacto con Berkeley para fondear el proyecto. En 1981 se lanzó la versión 4BSD con más de 400 envíos a todo el mundo. En 1982 Joy anunciá que deja Berkeley para incorporarse al equipo de Sun Microsystems y comienza a desarrollar Solaris, un sabor de Unix basado en BSD.
En 1985 los investigadores de la universidad Carnegie-Mellon comienzan a desarrollar su propio Kernel, conocido como Mach Kernel, el cual tomó librerias, código e ideas de BSD, si bien desarrollo e introdujo conceptos propios en su implementación de Unix. Posteriormente el Mach kernel sería usado para los sistemas de la empresa NeXT, la cual, a su vez, fue comprada por Apple Computers en 1996. El Mach Kernel es la base del Mac OSX actual y existe un versión que puede descargarse gratuitamente (claro, sin el ambiente gráfico) llamado OpenDarwin.
En 1984 apareción 4.2BSD, con la cual se estrenaba el protocolo TCP/IP desarollado por la gente de Berkeley. Está versión de BSD fue quizás su mayor éxito vendiéndose miles de licencias, al grado de que las empresas comenzaron a migrar de Unix SysV al nuevo BSD pues poseía muchas facilidades de red y el nuevo sistema de archivos Berkeley Fast filesystem. Varias empresas comenzaron a acercarse a Berkeley para distribuir BSD por su cuenta.
Esto provoco una demanda de AT&T que tardo varios años en resolverse. Según Berkeley, el acuerdo de cooperación contemplababa el acceso al código fuente pero AT&T argumentaba que eso violaba sus derechos de autor pues en el código había secciones que le pertenecían. Todos los involucrados en el desarrolo de BSD tuvieron que testificar en el juicio y eso retrasaba el trabajo. Un grupo de desarolladores hicieron mejoras al kernel y lanzaron el primer NetBSD en 1993, poco tiempo después otro grupo lanzó FreeBSD. Por fin, en enero de 1994 el juez que llevaba el caso entregó una pequeña lista de archivos que debian reemplazarse de BSD y con ello la cuestión legal fue zanjada.
Theo de Raat, un talentoso y problemático desarrollador de NetBSD, tuvo problemas con otros miembros del equipo y por ello decidió comenzar su propio proyecto: OpenBSD. Este sistema operativo, se concentra en la portabilidad, el cumplimiento de normas y regulaciones, corrección, seguridad proactiva y criptografía integrada.

Agur