Canonical emite un comunicado sobre la seguridad de Snapcraft

A través del blog de Ubuntu, la compañía de Mark Shuttleworth ha emitido un comunicado en relación a los programas maliciosos de criptominado, detectados recientemente en su tienda de aplicaciones de paquetes snap (Snapcraft).

En ningún momento se pronuncia la palabra malware. Canonical abre su artículo con un debate filosófico sobre si el criptominado es legal o ético, para concluir explicando que la retirada de las apps 2048buntu y Hextrix (si Mark fuera Rajoy diría “esas aplicaciones de las que usted me habla”) se debió a que no estaba explicado el propósito secundario de las mismas: “No existen reglas contra el criptominado, pero engañar a los usuarios es un problema”.

La gente de Canonical incluso contactó con el desarrollador de la aplicación, el cual les informó de que su objetivo era monetizar el juego ya que la licencia (MIT) se lo permitía, ignorando las consecuencias sociales y técnicas. Incluso se ofreció a dejar de hacer eso una vez contactado. No hizo falta, Canonical rápidamente procedió a la retirada de todas su aplicaciones.

Más interesantes son las explicaciones sobre las medidas de seguridad existentes en Snapcraft y las que piensan implementar en un futuro. Según Canonical actualmente se realizan controles automatizadas y revisiones de tipo manual — en este último caso, solo cuando se detecta algún problema específico— similares a las que se realizan en las tiendas de software de otros sistemas operativos (iOS, Android, Windows). Personalmente no estoy seguro de que esa comparación favorezca a Snapcraft o de que incluso el grado de control en iOS vs Android sea similar.

Comentan en el artículo que la complejidad del software y la cantidad de programas hace imposible su revisión en detalle y se debe confiar más en el origen del producto, es decir la organización que provee el software, que en la aplicación en si.

Canonical ya está trabajando en una nueva característica para Snapcraft que permitirá crear cuentas verificadas a los proveedores de software. De esa manera los usuarios podrán identificar mejor al desarrollador o grupo de desarrolladores que están detrás de una snap y decidir sobre su instalación.

Además se reforzará el papel de la suite de seguridad AppArmor, introduciendo nuevas capacidades en forma de parches upstream, con dirección al kernel y de los que se podrán beneficiar el resto de distros.

En el comunicado se recuerda finalmente las características de seguridad avanzadas que incluye este formato de paquetes en cuanto a aislamiento del resto del sistema y las ventajas que proporciona a la hora de desarrollar y distribuir software compatible con cualquier sistema Linux. También de acceso a versiones nuevas de programas.

Veremos si las snaps y otros paquetes similares como Flatkpak, se acaban imponiendo entre los usuarios o continuamos con el modelo de repositorio tradicional. En él, los encargados del mantenimiento de una distro, empaquetan sus paquetes a partir del código fuente y deciden cuales estarán incluidos de forma predeterminada, añadiendo una capa de control de calidad, ausente en este tipo de tiendas. Incluso pueden ayudar a prevenir comportamientos abusivos como el que hemos mencionado.

El tiempo lo dirá, pero mientras tanto se agradece el esfuerzo de Canonical por tomar conciencia de este problema y considerar más medidas de seguridad en su plataforma de aplicaciones.

5 thoughts on “Canonical emite un comunicado sobre la seguridad de Snapcraft”

  1. Señor Paquito says:

    Ola tannhausser y concurrencia.

    En mi opnión los paquetes autocontenidos son, posiblemente, el camino a seguir, no sé si snap o faltpak, pero los problemas de dependencias de la paquetería tradicional le dificultan la vida en exceso a los usuario que no aspiran a ser más que eso, usuarios del sistema… y aún a veces a usuarios con cierto interés y conocimientos sobre el tema…

    No obstante, y al margen de problemas de seguridad como este del criptominado, este tipo de paquetería tampoco parece estar aún del todo madura como para que se distribuya en la tienda de aplicaciones al mismo nivel que los paquetes deb (en el caso de Ubuntu y derivados), y lo creo así, por ejemplo, por la falta de traducciones en muchos casos, lo cual sucede en aplicaciones tan populares como Gimp o VLC.

    Luego, hay otros problemas, como la imposibilidad que tienen las aplicaciones en este formato para acceder a las unidades montadas en el fstab, lo cual es un problema importante cuando, como hago yo, todos tus datos están en una partición “ad hoc” común para varios sistemas que se monta al inicio en fstab. He visto que Ubuntu Software permite dar permiso de acceso a ficheros (no así Discover, de Plasma, que no ofrece de momento esta opción, en Kubuntu o KDE Neon tengo que hacerlo instalando los snap por terminal con el argumento –classic), pero solo sirve para unidades montadas manualmente o aquellas particiones que se monten al inicio como externas, sin usar el fstab (cosa que en Plasma es muy fácil de hacer, pero que no sé hacer en Gnome).

    Resumiendo, la idea de los paquetes autocontenidos me parece muy buena, pero aún les queda cierto recorrido para que lleguen a ser la solución universar que pretenden ser, por eso creo que deberían estar en un aparte específico de la tienda que dejase claro el carácter esperimental de este tipo de paquetería.

    Y conste que algún snap uso a diario, como Spotify, por ejemplo… (porque en Spotify no me causa ningún trastorno los problemas de acceso a ficheros)…

    Saludos.

    1. Señor Paquito says:

      Por cierto, me corrijo a mí mismo.

      Acabo de probar otra vez y he visto que con una instalación de un snap desde Ubuntu Software ni siquiera se puede acceder a particiones montadas manualmente. Solo puede hacerlo si lo instalamos con el argumento –classic (con dos guines) y con las particiones montadas manualmente, no accede a particiones montadas en el fstab.

      Saludos.

  2. kj says:

    En lo personal, a snap y flatpak les veo un futuro de nicho/casos específicos más que para reemplazar los .deb y .rpm de toda la vida. Vienen excelentes para algunos casos, pero en la mayoría solo te vas a comer un riesgo de seguridad, más peso en las aplicaciones, actualizaciones más pesadas (para en un futuro ser igual de molestas en en Windows) y alguna diferencia provocada por el sadbox. Todos esos problemas te los ahorras usando los paquetes de toda la vida.

    1. Raul P says:

      Se nota que no has tenido que luchar con las dependencias. Hace unos años era un calvario instalar codeblocks en debian, tenía que añadir los repos de ubuntu para poder hacerlo. Que no se te ocurra instalar la última versión de un software en una distro mal llamada “estable”, vas a tener que tirar de make para el software y casi todas sus dependencias.

      1. Tomás says:

        Algunos olvidan el infierno de las dll en Windows esparramadas por todo el sistema, un caos incontrolable nido de inestabilidades y problemas de seguridad, ¿queremos eso en GNU/Linux? ¡Yo no!

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.