viernes, septiembre 27, 2013

Iberpix: Un visor de la topografía española

A la hora de conocer sitios, muchos hemos usado el estupendo Google Maps: sus imágenes por satélite o la posibilidad de navegación en 3D son características que aportan mucho valor al producto . No pocos han colaborado subiendo fotos a Picassa o Panoramio, que luego Google utiliza para ilustrar sus mapas. También lo hemos usado para calcular rutas o planificar excursiones.

Sin embargo, siempre he pensado que estaba cojo en un aspecto: Le falta información sobre la topografía: Los nombres de los lugares: cabos, montañas , valles o ríos. Excepto los más importantes la anterior información no está presente en Google Maps. Sin embargo hay una gran alternativa, al menos en España, que es la aplicación Iberpix del Instituto Geográfico Nacional. Esta aplicación pone a disposición de todo el mundo una inmensa base de datos de información de la geografía española. Una de las cosas más que más me gusta es la calidad de los mapas y la cantidad de información que tienen. Tampoco se queda atrás las imágenes por satélite que tiene en una de las capas, comparadas con el Google Maps.

En las siguientes dos capturas pueden verse las capas de satélite de Google Maps y de Iberpix.


Ribadesella, Google Maps

Ribadesella, Iberpix

La siguiente captura es la capa de mapas de Iberpix, donde puede apreciarse la riqueza y detalle de información disponible


miércoles, septiembre 18, 2013

Verificar firmas de binarios en MacOS X con codesign

Una sana costumbre cuando uno se baja de Internet cualquier programa es intentar verificar su autenticidad: que el creador sea el que dice ser y que el binario no ha sido alterado por terceros. La manera tradicional de hacer esto es usar algún tipo de función hash y técnicas de firmado digital que permitan comprobar que el binario es auténtico. El lado malo: normalmente tenemos complicado verificar la autenticidad de las claves públicas en las que se apoya estos procesos.

Algunos sistemas operativos han incluido en sus últimas versiones servicios que permiten comprobar la autenticidad e integridad de programas que se bajan de Internet, siempre que hagan uso de estas facilidades. En el caso del MacOS X esta infraestructura empezó a aparecer en la versión 10.5 (Leopard) del sistema operativo. A través del comando codesign se puede realizar operaciones de firma digital de los binarios que la incorporen.

La herramienta da la oportunidad de comprobar las firmas digitales tanto de un fichero en disco como de una aplicación que esté ejecutándose en ese momento. Por ejemplo:

codesign --verify --verbose /Applications/Twitter.app
/Applications/Twitter.app: valid on disk
/Applications/Twitter.app: satisfies its Designated Requirement

De igual manera, se puede verificar la integridad de un proceso que esté ejecutándose en el sistema. En este caso, en vez de un path se le pasa el PID del proceso. En este ejemplo verificaría la integridad del proceso cuyo PID es 1234

swordcoast:~ terron$ codesign --verify --verbose 1234

También se puede obtener información sobre la firma criptográfica de un binario con ayuda de la opción --display

codesign --display --verbose=4 /Applications/Twitter.app
Executable=/Applications/Twitter.app/Contents/MacOS/Twitter
Identifier=com.twitter.twitter-mac
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=14072 flags=0x200(kill) hashes=697+3 location=embedded
Hash type=sha1 size=20
CDHash=4db441b1c36dfaf0edb5d548c78587b0037698c1
Signature size=4169
Authority=Apple Mac OS Application Signing
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Info.plist entries=32
Sealed Resources rules=5 files=124
Internal requirements count=2 size=344

La última versión de MacOS X, Mountain Lion, y a partir de la versión 10.7.5 de Lion , se tiene una infraestructura llamada GateKeeper que permite la configurar el sistema para evitar la ejecución de aquellos programas que no cuenten con una firma digital válida.

Si el binario que nos bajamos no tiene firma digital, es aconsejable usar algún tipo de servicio, como VirusTotal para pasar el programa por una batería de antivirus.

Por supuesto, todo este proceso de verificación implica que nos fiamos de Apple y de la cadenas de criptografía que lleva el sistema operativo. No voy a ser iluso, si cualquier agencia estatal deseara que instalásemos un binario con un troyano, no creo que le cueste mucho convencer a Apple que le firme un binario "aliñado" que el sistema se lo tragase sin problemas.


Technorati Tags:

viernes, agosto 30, 2013

diskutil: Información de los discos en OS X en el CLI

Una de las cosas que más me gusta de MacOS X es la posibilidad de trabajar tanto con la interfaz gráfica como con la línea de comandos. De vez en cuando hay que realizar operaciones de mantenimiento de discos en las que queremos averiguar información sobre el mismo. La utilidad que se encarga de gestionar los discos es diskutil. Este comando admite varios verbos cada uno de los cuales invoca una función determinada. Aquí van algunos de los que permiten obtener información. Si se le añade a cualquiera de los dos el modificador -plist, se volcará la información en dicho formato.

diskutil list

Permite listar todos los discos que haya en el sistema - incluye los CDROM / DVD -, dando información sobre las particiones que tienen: tamaño, tipo, nombre de la partición y el nombre de dispositivo que aparecerá bajo el directorio /dev:

/dev/disk0
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *121.3 GB   disk0
  1:                        EFI                         209.7 MB   disk0s1
  2:                  Apple_HFS Macintosh HD            120.5 GB   disk0s2
  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *80.0 GB    disk1
  1:                        EFI                         209.7 MB   disk1s1
  2:                        ZFS zfs                     39.9 GB    disk1s2
  3:                  Apple_HFS hfsformat               39.7 GB    disk1s3

diskutil info path_disco

Permite obtener información sobre un disco físico o partición. Ejecutando la orden anterior sobre el disco /dev/disk0:

   Device Identifier:        disk0
   Device Node:              /dev/disk0
   Part of Whole:            disk0
   Device / Media Name:      APPLE SSD SM128E Media

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Content (IOContent):      GUID_partition_scheme
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified

   Total Size:               121.3 GB (121332826112 Bytes) (exactly 236978176 512-Byte-Blocks)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)
   Ejectable:                No

   Whole:                    Yes
   Internal:                 Yes
   Solid State:              Yes
   OS 9 Drivers:             No
   Low Level Format:         Not supported

Technorati Tags:

martes, agosto 27, 2013

Controlar la generación de paquetes Debian a través de DEB_BUILD_OPTIONS

Las opciones de construcción de paquetes Debian a través dpkg-buildpackage pueden controlarse con la variable de entorno DEB_BUILD_OPTIONS. Algunos de los posibles cambios son no ejecución de los tests, desactivar las optimizaciones o no quitar la onformación de depuración de los binarios. Pueden combinarse los diferentes valores para compilar el paquete de acuerdo con las necesidades que se tengan. Las posibles opciones de la variable son las siguientes:

  • nocheck El sistema de paquetes no ejecuta los posibles tests que puede tener el paquete (si el paquete usa las autotools para generarse normalmente esto equivale a no hacer el make check)
  • noopt Desactiva las optimizaciones, explícitamente pasa los flags -O0 -g al compilador (que como suele ser el gcc implica desactivar la optimización y activar la generación de los símbolos de depuración).
  • nohardening Desactiva las opciones que permiten introducir mecanismos en los binarios para prevenir la explotación de fallos de seguridad en los mismos (si se tiene instalado los paquetes para ello en Debian). Se puede ver más sobre en el wiki de Debian en Hardening.
  • nodocs No construye los paquetes de documentación.
  • nostrip La información de depuración no debe quitarse de los binarios generados durante la instalación.
  • parallel=n Si el paquete permite la construcción en paralelo, usar hasta n procesos.

Referencias


Technorati Tags: ,

miércoles, agosto 21, 2013

Quinto aniversario del accidente del vuelo JKK 5022

Ayer se cumplieron cinco años del desgraciado accidente del vuelo JKK 5022 operado por la desaparecida Spanair, que acabó con un balance de ciento cincuenta y cuatro muertos y dieciocho heridos. Toda la prensa nacional ha publicado artículos recodando la tragedia, pero me ha sorprendido el tono de todos ellos, porque dan a entender que no se sabe la verdad o no hubo un juicio justo. Por ejemplo El Mundo titula Familiares de Spanair critican a los jueces 'por quitarse el muerto de encima', El País Las víctimas del accidente de Barajas piden indemnizaciones como las del 11-M y el Abc Los afectados por el accidente de Spanair critican a los jueves por archivar el caso. En cualquiera de los enlaces anteriores hay declaraciones como la siguiente:

«siguen pidiendo justicia y que se conozca la verdad desde que el año pasado la Audiencia Provincial de Madrid archivara el caso para quitarse el muerto de encima y evitar responsabilidades penales».

Sin embargo, creo que la verdad se sabe. Y está perfectamente documentada en los informes del CIAIAC sobre el accidente. Si nos vamos al informe final, en la página 254, el apartado 3.2 Causas se dice lo siguiente:

La tripulación perdió el control del avión como consecuencia de la entrada en pérdida inmediatamente después del despegue, por no haber configurado el avión correctamente, al no realizar la acción de despliegue de los flaps/slats, tras una serie de fallos y omisiones, junto con la ausencia de aviso de la configuración incorrecta de despegue.
La tripulación no detectó el error de configuración al no utilizar adecuadamente las listas de comprobación que contienen los puntos para seleccionar y comprobar la posición de flaps/slats en las labores de preparación de vuelo, en concreto:
  • No llevó a cabo la acción de seleccionar flaps/slats con la correspondiente palanca de mando (en «After Start Cheklist»);
  • No realizó la comprobación cruzada de la posición de la palanca y el estado de las luces indicadoras de flaps y slats al ejecutar la lista de comprobación «After Start»;
  • Omitió la comprobación de flaps y slats en el punto «Take Off Briefing» de la lista de comprobación de taxi;
  • n la comprobación visual realizada en la ejecución al punto «Final Items»

Si, se puede entrar en la discusión de que si el TOWS hubiese funcionado bien podrían haber sido advertidos los pilotos que la configuración del despegue era la correcta y no se hubiese producido el accidente, pero eso no cambia la raíz del problema: Casi seguro si el avión hubiese estado bien configurado no se habría estrellado. En el mismo informe se afirma (página 83).

Estas evidencias se corresponderían con la palanca de flaps/slats posicionada en UP/RET en el momento en el que se produjo dicho impacto entre tetón y guía.

Además la información grabada en el FDR (caja negra con los parámetros de vuelo) apoyan la afirmación anterior.


Technorati Tags: