¿Es Snap inseguro? Que no cunda el pánico aún.

Estos días, además de el exitoso lanzamiento de Ubuntu 18.04 y de que ya se sabe por dónde tirará Ubuntu 18.10, la noticia es que se ha descubierto un uso fraudulento de las aplicaciones Snap, promocionadas por Canonical. En este caso, un usuario distribuyó como software privativo empaquetado como Snap un fork del juego 2048, disponible como licencia MIT, al que le añadió un programa de minado de criptomonedas que se disimulaba como un proceso más de systemd. La aplicación, para que fuese escogida con facilidad, tenía el nombre de 2048buntu. En cuanto se dio la alarma, gracias a un usuario, Canonical ha suspendido la cuenta y retirado todas las aplicaciones subidas por este usuario de la tienda hasta nuevo aviso, por lo que lo que podía ser parece estar mitigado.

Si bien la respuesta de Canonical ha sido ejemplar y rápida, este suceso pone el foco en como se acepta software en la tienda de Snap. De momento, lo existente son controles automáticos, que por lo que se ve no están preparados para encontrar este tipo de fallas. Quizás sea momento de que en Canonical empiecen a primar la calidad sobre la cantidad en esta guerra que se traen por la supremacía del empaquetado de apps en Linux.

Si nos vamos a debates más profundos, esto además revela problemas de construcción de las licencias libres. Cuando se debate sobre si GPL o MIT o cualquiera de las otras, una de las líneas principales de debate es sobre si la libertad de poder privatizar el código es necesaria o no. Muchos programadores, con normal preocupación sobre si podrán vivir de lo suyo, suelen defender la necesidad de que el código pueda ser privado, ya que este suele ser más rentable económicamente.

Esta es la vía por la cual la mayor parte de empresas suelen estar más cómodas con licencias de este tipo frente a la GPL, que obliga a que todo sea libre una vez se implementa, tanto el original como los derivados. Sin embargo, y ya no hablando del aprovechamiento tradicional que hacen muchas empresas de la comunidad para después cerrar todo a cal y canto, es evidente que permitir a cualquiera cerrar el código facilita en cierta medida este tipo de sucesos. Crear un Caballo de Troya (troyano es otra cosa cuando hablamos de seguridad), empaquetando un software de minado como un inocente juego, teniendo que publicar todo el código se hace muchísimo más difícil.

De ahí que el problema de Snap (y de cualquier otro software que se distribuya) al final no es tanto los controles que se hagan sobre código abierto, si no lo limitados que estamos cuando este se cierra. El debate de toda la vida, vamos.

Acerca de isorfe

Lignuxero novato, charlatán por vocación. Me dedicaba a migrar de Ubuntu a Debian y viceversa cuando me dejaban un rato a solas delante de un ordenador, ahora lo mismo pero entre Manjaro y Antergos.Los tiempos cambian, el distrohopping permanece.

3
Deja una respuesta

avatar
2 Hilos de comentario
1 Respuestas de hilo
1 Seguidores
 
Comentario más reaccionado
El hilo de comentarios más caliente
3 Autores de comentarios
Señor PaquitoisorfeCarlos Autores de comentarios recientes
  Suscribirse  
Los más recientes Los más antiguos Más votados
Notificarme las
Señor Paquito
Invitado
Señor Paquito

De todos modos, al margen de problemas de seguridad como estos, los snap tienen deficiencias ciertas funcionales como, por ejemplo, a la escasez de snaps con las mismas traducciones que sus equivalentes .deb o, lo que ya es más grave, la imposibilidad de acceder a particiones montadas (por lo menos yo no puedo hacerlo), lo cual hace imposible usarlos si, como sucede en mis sistemas, tus datos están en una partición aparte que se monta al inicio.

Conste que el comncepto de paquetes autocontenidos me parece el camino a seguir, pero, al menos en el caso de los snap (que es lo que he probado) aún no tienen la sufuiciente madurez como para ofrecerlos en la tienda de aplicaciones al mismo nivel que sus equivalentes .deb, como si realmente fueran totalmente funcionales.

Saludos.

Carlos
Invitado
Carlos

Creo que este problema debería abordarse desde una perspectiva más técnica, ya que Snap a diferencia de Flatpak, permite la ejecución arbitraría de daemons bajo demanda, algo que fue utilizado aquí para incluír malware. ¿cuál es el objetivo de esto?, poder empaquetar sin mayores limitaciones software para servidores o aplicaciones CLI, entonces ¿porqué no limitar estas características para aplicaciones de escritorio?

Suscríbete gratis

Suscríbete gratis

Recibe las últimas noticias y novedades de LiGNUx en tu email.
Sin publicidad, sin Spam.

Gracias por suscribirte a LiGNUx.