Felipe Alfaro Solana

Today, I was trying to resize a logical volume of one of my systems running Fedora Core 5, configured with two LVM volumes (one for the root filesystem and another one for swap) on top of a software RAID-0. Since the volume I wanted to shrink holds the root filesystem, I had to boot from the Fedora Core 5 rescue CD in order to reduce the filesystem (ext2online didn’t allow me to reduce the filesystem on the fly), then reducing the volume itself.

Thus, I booted from the Fedora Core 5 DVD by entering linux rescue at the syslinux prompt, then choosed English for both the system language and keyboard layout. Since I was lazy, and didn’t want to manually set up the RAID disks and search for LVM volumes, I told Anaconda to scan the system for a Linux installation and mount it read-only under /mnt/sysimage.

What I didn’t know is that Anaconda also spawns up /mnt/sysimage/usr/bin/bash as the shell (instead of /bin/bash which is the one I expected), appends /mnt/sysimage/bin:/mnt/sysimage/sbin:\
/mnt/sysimage/usr/bin:/mnt/sysimage/usr/sbin:\
/mnt/usr/X11R6/bin to PATH and appends /mnt/sysimage/lib:/mnt/sysimage/usr/lib to LD_LIBRARY_PATH. So, when I tried to umount /mnt/sysimage it failed with a Device or resource busy error message:

# umount /mnt/sysimage/boot
# umount /mnt/sysimage/dev
# umount /mnt/sysimage/selinux
# umount /mnt/sysimage/sys
# umount /mnt/sysimage/proc
# umount /mnt/sysimage
umount: Device or resource busy

The solution was easy, however:

# exec /bin/bash
# umount /mnt/sysimage
# echo $?
0

The modrdn LDAP operation allows an authorized user to rename an LDAP entry’s RDN (that is, modifying the RDN of that entry).

Optionally, the modrdn operation can keep the old attributes that form the pristine RDN. This can be accomplished by specifiying deleteOldRDN:0 at the end of the modrdn data. If deleteOldRND:1 is specified at the end of the modrdn operation, or it is not specified at all, the modrdn operation will keep the attributes (and its values) that formed the pristine RDN.

For example, let’s add a sample entry:

$ ldapmodify ...
dn:cn=John Smith,ou=People,dc=sample,dc=com
changeType:add
objectClass:top
objectClass:person
cn:John Smith
sn:Smith

The attributes for the newly added entry are:

$ ldapsearch -x \
  -b"cn=John Smith,ou=People,dc=sample,dc=com" \
  -s base
dn: cn=John Smith,ou=People,dc=sample,dc=com
objectClass: top
objectClass: person
cn: John Smith
sn: Smith

Now, using the ldapmodify command, let’s invoke the modrdn operation onto the sample entry:

$ ldapmodify ...
dn:cn=John Smith,ou=People,dc=sample,dc=com
changeType:modrdn
newrdn:cn=John A. Smith
deleteOldRDN:1

Since deleteOldRND:1 has been specified, the old cn attribiute (commonName), which was part of the RDN, is removed and then replaced by the new cn attribute and it’s new value.

$ ldapsearch -x \
  -b"cn=John A. Smith,ou=People,dc=sample,dc=com" \
  -s base
dn: cn=John A. Smith,ou=People,dc=sample,dc=com
objectClass: top
objectClass: person
sn: Smith
cn: John A. Smith

Should have we specified deleteOldRND:0, then the entry would have looked as follows:

$ ldapsearch -x \
  -b"cn=John A. Smith,ou=People,dc=sample,dc=com" \
  -s base
dn: cn=John A. Smith,ou=People,dc=sample,dc=com
objectClass: top
objectClass: person
cn: John Smith
cn: John A. Smith
sn: Smith

Acabo de leer acerca de una propuesta de sistema anti-phising denominada Garante. Lo curioso de esta propuesta es no sólo que es Española, sino que difiere bastante de otras de las propuestas realizadas en la actualidad. También me sorprende que, según la documentación que he leído, el autor parece estar regañado con las tildes (me he permitido el lujo de realizar las correciones ortográficas pertinentes cuando hago referencias literales a la documentación).

A continuación paso a comentar algunos párrafos del documento técnico de Garante:

En vez de intentar recopilar lo mas rápidamente posible firmas para identificar servidores web falsos, lo que hace es tener una base de datos de firmas capaces de identificar unívocamente un sitio web de forma 100 % confiable tanto en su contenido como en su direccionamiento IP. Para esto emplea técnicas criptográficas.

Garante funciona de la siguiente manera:

• Descarga una base de datos con los “hash” SHA2 del contenido HTML del servidor web y de su dirección IP. Esta base de datos está firmada digitalmente.
• Verifica la firma digital de la base de datos con la clave pública que dispone.
• Se conecta al servidor web y descarga el código HTML de la página.
• Realiza un hash criptografico del HTML que ha obtenido.
• Compara el resultado que ha obtenido con el que aparece en la base de datos.
• Realiza la resolución nombre-dns –> dirección IP.
• Genera un hash criptografico de la dirección IP que obtiene de la resolución.
• Compara el Hash con el de la base de datos.
• Si todas las comprobaciones han sido satisfactorias y las operaciones criptograficas demuestran que el sitio al que se va a acceder no ha sido alterado o modificado, se lanza el navegador para acceder.

No entiendo por qué resume de forma separada el contenido de la página Web y la dirección IP, en lugar de hacer el resumen conjunto de ambas. Tampoco entiendo, cuando habla de SHA-2, a qué versión de la familia SHA-2 se refiere, al igual que la implementación utilizada de dicho algoritmo (compatible FIPS, OpenSSL, etc.).

De este modo, si el servidor desde el que se descargan las bases de datos fuera comprometido y las bases de datos alteradas, en este punto “Garante” detectaría la inconsistencia e informaría de la incidencia.

Entiendo que para conseguir que el servidor desde el que se descargan las bases de datos sea suficientemente seguro para aguantar una intrusión es que el proceso de firma de las bases de datos se realice de forma separada, en una máquina aislada, y preferiblemente sin conexión a la red. Si el proceso de firma se realiza en la misma máquina que almacena la base de datos, un intruso podría alterar la base de datos y firmarla.

Los sistemas anti-phising actuales se basan en la premisa de una actualización constante por parte del usuario y en optimizar los tiempos de respuesta a la hora de detectar e incluir en sus bases de datos los sitios que albergan contenido malicioso.

Realmente no veo mucha diferencia entre los sistemas actuales y Garante: ambos deben actualizarse periódicamente: Los bancos pueden cambiar ligeramente su página de acceso, pueden cambiar de dirección IP, etc. Lo que sí me parece significativo es el hecho de que Garante utiliza la política “todo aquello que no está explícitamente permitido está prohibido” lo cual me parece un aspecto muy positivo.

“Garante” emplea tecnología PKI pero tan solo necesita un par de claves publica (distribuida con el cliente) y privada (en manos de la organización) para verificar el origen de los datos.

Destacar que PKI no es una tecnología, sino una infraestructura formada por múltiples tecnologías y estándares. Aprovecharse de una PKI no hace que un producto sea automáticamente seguro. ¿Qué ocurre con las claves de firma que se utilizan para autentificar la base de datos? ¿Dónde se almacenan? ¿Existen copias? ¿Qué longitud de clave tienen? ¿Qué ocurrirá cuando el certificado asociado a la clave pública utilizada para comprobar la firma caduque? ¿Cómo se renueva? ¿Instalando una versión nueva del software? ¿Actualizándolo?

El origen de los datos no es lo único que debe interesar al usuario, sino su integridad. Puede que los datos procedan del repositorio central de eGarante pero, ¿qué garantiza que dichos datos son correctos y están al día? ¿Qué ocurre si un banco cambia de dirección IP? ¿O si el banco tiene una página de acceso para clientes que cambia periódicamente? Tendrá que existir un acuerdo tácito entre eGarante y el banco. ¿Qué ocurre si el número de bancos aumenta considerablemente? ¿Es escalable el sistema?

Así mismo, eGarante no puede proteger el usuario contra otros tipos de ataques, como capturadores de teclado (keyloggers), parásitos o troyanos.

Evitar confusiones: Al ser un elemento independiente del navegador se evita caer en confusiones y que, por ejemplo, una pagina web maliciosa trate de simular la interface o mecanismos de respuesta del programa dejando al usuario en una situación de indefension.

La independencia con respecto al navegador me parece un aspecto muy positivo, precisamente porque la mayoría de los usuarios sólo esperan ver un candado cuando intentan acceder de forma segura a la página de su banco, pero no saben con certeza en qué lugar de la pantalla debe aparecer dicho candado. En algunos navegadores el candado aparece en la barra de estado, mientras que en otros aparece en la barra de título (como Safari). Pero ninguno lo hace dentro de la zona visual del navegador. Separando el proceso de validación del navegador ayuda a evitar confusiones o malos entendidos por parte del usuario.

Un problema que encuentro es que se trata de una solución cerrada. Al no disponer del código fuente, me resulta imposible saber cómo funciona realmente este sistema. Así mismo, al ser una solución cerrada estoy dejando, en cierta medida, en manos de un tercero la capacidad de decidir si un sitio es auténtico o no. ¿Quién me garantiza que ese software funciona correctamente? Por añadido, es una aplicación autónoma para sistemas Windows. ¿Qué ocurre con el resto de usuarios, como los usuarios de GNU/Linux, FreeBSD, NetBSD, OpenBSD, Solaris o Mac OS X?

Parece que la distribución de la base de datos queda en manos de una sola entidad: el fabricante. ¿Qué ocurre si el fabricante sufre una intrusión? Su base de datos queda automáticamente comprometida. Quizá sería interesante implementar un modelo algo más descentralizado, de manera que la descarga de la base de datos pueda hacerse a través de varios sitios, que firman con claves diferentes, a fin de obtener ciertas garantías de la integridad de la base de datos. Otra solución es separar físicamente el proceso de firma del proceso de generación y distribución de la base de datos. Incluso me parecería interesante descentralizar el proceso de firma, por ejemplo en N entidades (separadas físicamente), de manera que la base de datos deba ser firmada simultáneamente por todas ellas. De esta forma, para poder comprometer la base de datos sería necesario comprometer N procesos de firma digital.

Otro punteo que quiero resaltar es que Garante no deja de ser un programa autónono, y por ello, comprometible. No creo que fuera demasiado difícil desarrollar un gusano o virus que se instale en el sistema, desactive, reemplace o comprometa el software de Garante. Podría ser interesante desarrollar un sistema de desafío, por el cual el cliente desafíe al sitio Web a que realice algún tipo de operación, cálculo o proceso, que sólo éste sabe o puede hacer, pero cuyo resultado pueda ser comprobado por el usuario.

Como conclusión, decir que me parece una propuesta interesante, aunque hay ciertos aspectos que no veo demasiado claros, como la apertura de código, independencia tecnológica del sistema operativo y la descentralización del sistema para repartir los puntos de ataque.

“Hay dos clases de personas en este mundo, buenas y malas. Las buenas duermen mejor, pero las malas parecen disfrutar el día más.”
– Woody Allen.

Although nearly every GNOME or KDE application has native support for printing to PDF files, there are still applications out there which do not support this feature. One example are Windows applications ran under WINE.

Although WINE-emulated Windows applications use the CUPS printing system, they are unable to print directly to a PDF file, like GNOME, KDE or Mac OS X applications do. Fortunately, there exists CUPS-PDF, an open source project which implements a virtual PDF printer. WINE-emulated Windows applications can print to the CUPS-PDF virtual printer which will magically create a PDF file from any print job sent to it and place it under directory /var/spool/cups-pdf/$USER.

CUPS-PDF works by installing a CUPS printer, named Cups-PDF, supported by the custom cups-pdf backend which takes a PostScript input file and writes out a PDF output file using GhostScript’s pdfwriter driver.

I have been experiencing problems when converting PostScript print jobs to PDF documents. Fedora Core 5 uses ESP GhostScript 8.15 by default and it seems to have problems with embedded images. Although the PDF document seems to get written successfully, trying to open it up using Adobe’s Acrobat Reader throws a “Drawing error” message and an blank page. Using AFPL GhostScript 8.53 instead seems to fix the problem and it’s currently working pretty very well for me.

I have created two custom RPM packages for Fedora Core 5:

• cups-pdf-gs-8.53-1.src.rpm

  This RPM package wraps AFPL GhostScript 8.53, relocated under /usr/lib/cups-pdf-gs-8.53, along with Type1 and PFM fonts taken out from the GhostScript and urw-fonts packages.

  The AFPL GhostScript’s gs processor is able to transform a PostScript document with images embedded into a PDF file which Adobe Acrobat Reader is able to display and print.

• cups-pdf-2.1.0-1.src.rpm

  This RPM package is based upon the original but includes a few tweaks:

  1. A tweaked color PostScript PPD file.

     I had to adjust the *ImageableArea directives (which control margins) since the original values caused undesired clipping and wrapping in the generated PDF documents.

     The tweaked PPD file also changes the default paper layout from Letter to A4, since the latter is what most people use here in Europe.

  2. A tweaked cups-pdf.conf file.

     The original CUPS-PDF configuration file, cups-pdf.conf, uses /usr/bin/gs to convert from PostScript to PDF. I had to adjust the path to the GhostScript interpreter (GhostScript directive) in order to point to one packaged inside the AFPL GhostScript 8.53 RPM packaged, which lies at /usr/lib/cups-pdf-gs-8.53/bin/gs

One last thing: the %postinstall script of cups-pdf-2.1.0-1.src.rpm invokes /usr/sbin/lpadmin -p Cups-PDF -v cups-pdf:/ -m PostscriptColor.ppd -E to set the virtual PDF printer up. However, I have noted that lpadmin installs the PostscriptColor.ppd file, but changes the paper defaults from A4 to Letter.

UPDATE:

As of ghostscript-8.15.1-8 (ESP GhostScript 8.15 r128), the problem with the pdfwriter seems to have been fixed: Fix pdfwrite (bug #187834)