Monthly Archives: May 2024

GNOME OS promete actualizaciones rápidas y seguras con systemd-sysupdate

Posted on by

GNOME OS , una distribución experimental para que los desarrolladores evalúen el estado de desarrollo del entorno de escritorio

Con el lanzamiento de systemd 251, que se realizó en mayo de 2022, se marcó la introducción de systemd-sysupdate, un nuevo sistema de actualización que promete una mayor integración con systemd, soporte para diseños basados en imágenes y una cadena de confianza completa desde el inicio del sistema, tanto en línea como fuera de línea.

Este enfoque de systemd-sysupdate llamo la atención de los desarrolladores de GNOME OS (la distribucion experimental que introduce lo último en desarrollo del escritorio), los cuales han anunciado la transición al uso del componente systemd-sysupdate para organizar sistemas de actualizaciones atómicas.

Los desarrolladores mencionan que este cambio tiene como objetivo adaptar las compilaciones nightly de GNOME OS para realizar un control de calidad diario del desarrollo de GNOME. Como parte del proyecto, la migración implica el proceso de arranque y el sistema de archivos, así como la integración de systemd-sysupdate con GNOME a través de un servicio D-Bus y polkit para permitir la gestión de actualizaciones por parte de software no privilegiado.

Se menciona que actualmente, el sistema OSTree se utiliza para crear y actualizar el contenido de la partición root de GNOME OS, actualizando la imagen del sistema de manera atómica desde un repositorio similar a Git.

La partición del sistema se monta en modo de solo lectura, y las actualizaciones se entregan en forma de pequeñas porciones que contienen cambios relacionados con el estado anterior (actualizaciones delta). Esto permite, por ejemplo, durante el proceso de prueba de GNOME, revertir fácilmente el sistema a versiones anteriores y comprobar si un error identificado aparece en ellas.

Una de las ventajas de cambiar GNOME OS de OSTree a systemd-sysupdate es la capacidad de utilizar un proceso de inicio verificado, donde la cadena de confianza se extiende desde el gestor de arranque hasta los componentes del sistema de la distribución. Además, el uso de systemd-sysupdate permitirá una integración más completa con systemd y una arquitectura que manipule imágenes del sistema prediseñadas como componentes indivisibles.

Ahora bien, para completar esta migración, hay dos trabajos principales involucrados.

El primero es migrar el proceso de arranque y el sistema de archivos root … La segunda parte es la integración de sysupdate con GNOME. Actualmente, las actualizaciones del sistema sólo se pueden gestionar con una herramienta de línea de comandos, que debe ejecutarse como root. 

En el último trimestre del año pasado se llevaron a cabo experimentos para crear imágenes de sysupdate con soporte para UEFI Secure Boot. Actualmente, hay disponibles dos versiones de compilaciones de GNOME OS: una basada en OSTree y otra en systemd-sysupdate. Queda por garantizar que sysupdate se integre completamente con GNOME y proporcione una interfaz gráfica para actualizar el sistema.

En este momento, las actualizaciones basadas en sysupdate solo se pueden gestionar desde la línea de comandos y requieren privilegios de root. Para la integración con GNOME, ya se ha desarrollado un servicio D-Bus que, en combinación con Polkit, permite gestionar las actualizaciones con un usuario sin privilegios. El servicio D-Bus desarrollado y la utilidad updatectl asociada están destinados a incluirse en la versión principal de systemd.

Entre los problemas aun sin resolver está la necesidad de agregar soporte para actualizaciones delta a systemd-sysupdate (actualmente, las imágenes se cargan en su totalidad) y la creación de herramientas para mantener simultáneamente varias versiones del sistema operativo basadas en las ramas estable y en desarrollo de GNOME. Además, se ha comenzado a trabajar en un nuevo instalador para GNOME OS, que aún se encuentra en una etapa inicial y cuyo repositorio aún no se ha creado.

Finalmente se menciona que a futuro está previsto agregar la funcionalidad de gestión de actualizaciones basada en sysupdate a la aplicación de software GNOME. Para ello, se ha preparado un complemento experimental llamado gs-plugin-systemd-sysupdate, que implementa la capacidad de actualizar el sistema operativo a través del servicio D-Bus para la actualización del sistema.

Según el anuncio oficial, Gnome OS también verá una integración más estrecha con systemd y soporte avanzado para el diseño basado en imágenes, lo que brinda inmutabilidad, actualizaciones automáticas, restablecimientos de fábrica y más.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/AcS3rN5
via IFTTT

openSUSE presentó la primera preview de Agama 8, el nuevo instalador de SUSE y openSUSE

Posted on by

instalador Agama

A finales del mes de Febrero de este año, compartimos aquí en el blog una publicación relacionada con la información proporcionada por openSUSE sobre la hoja de ruta para el desarrollo del nuevo instalador en el que ha estado trabajando durante ya varios meses.

Anteriormente conocido como D-Installer, Agama se distingue por separar la interfaz de usuario de las partes internas de YaST, permitiendo el uso de diversas interfaces, como una interfaz web para gestionar la instalación.

En la publicación que compartimos, mencionábamos que openSUSE presentaría dos actualizaciones importantes de Agama para este año. La primera está prevista para mediados de abril y la segunda para mediados de julio.

El equipo de YaST vuelve con más noticias sobre Agama . En nuestra publicación anterior, expusimos los dos primeros pasos de nuestra hoja de ruta para 2024: una interfaz de usuario más potente para la configuración del almacenamiento y una nueva arquitectura sin Cockpit con una mejor API para llamadas externas. Ahora estamos orgullosos de anunciar Agama 8, que ofrece versiones iniciales de ambas funciones.

La primera de ellas ya se ha presentado y en la nueva versión de Agama, se presenta una arquitectura completamente renovada, marcando una transición del uso de módulos preexistentes desarrollados por el proyecto Cockpit hacia un marco independiente con una interfaz de usuario modernizada.

En lugar de D-Bus, ahora se utiliza HTTP como protocolo de comunicación principal para la interacción entre los componentes de Agama. Este cambio a HTTP ha ampliado la capacidad del proyecto para integrarse con sistemas más grandes y ha simplificado la organización de instalaciones automatizadas.

Se menciona que el dejar de lado el uso de Cockpit permitió eliminar dependencias externas adicionales, como los componentes en Python y C que Cockpit requería, mientras que Agama utiliza Ruby y Rust. La eliminación de Cockpit también liberó a los desarrolladores de las limitaciones encontradas al implementar modos de instalación automática y les permitió rediseñar la interfaz de configuración de almacenamiento, logrando un equilibrio óptimo entre simplicidad para principiantes y funcionalidad para usuarios avanzados.

Además, la nueva arquitectura ha reducido significativamente el tiempo de inicio del instalador y ha mejorado su rendimiento, manteniendo la capacidad de utilizar componentes de bajo nivel ya probados. Entre las características que aún no se han transferido a la nueva implementación se encuentran el emulador de terminal integrado y las herramientas para gestionar dispositivos DASD (Dispositivo de almacenamiento de acceso directo) y zFCP (SCSI-over-Fiber Channel).

Además de la nueva arquitectura, Agama 8 ofrece una interfaz completamente rediseñada y más funcional para configurar el almacenamiento y particionar discos. Esta interfaz conserva todas las capacidades básicas del sistema clásico de configuración de almacenamiento YaST y permite una personalización avanzada, pero también ha sido adaptada para ser más fácil de entender para los principiantes. Por ejemplo, la nueva interfaz permite seleccionar la ubicación de cada partición LVM o volumen lógico, montar o reformatear sistemas de archivos previamente accesibles, configurar opciones de cifrado y arranque, y cambiar el tamaño de las particiones.

Los cambios también incluyen una nueva interfaz para seleccionar conjuntos de aplicaciones, configuraciones mejoradas para el cifrado de disco completo basado en TPM, una pila de red completamente reescrita, modernización de algunos widgets, interfaces mejoradas para editar parámetros de sistemas de archivos y crear usuarios, y una mejor visualización de los problemas encontrados durante la instalación. Además, Agama 8 está traducido a 10 idiomas.

Ya estamos trabajando en Agama 9, que debería lanzarse dentro de un mes. La atención se centrará en mejorar el soporte para instalaciones desatendidas y la compatibilidad con AutoYaST.

Finalmente, se menciona que en aproximadamente un mes, se espera el lanzamiento de Agama 9, que incluirá una importante reorganización de la interfaz web, aprovechará las oportunidades perdidas durante la transición a la nueva arquitectura y ampliará las opciones para la instalación automática sin intervención humana. El objetivo del desarrollo es ser compatible con AutoYaST y permitir que Agama se utilice como una alternativa a AutoYaST.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/QGmCFwi
via IFTTT

FerroChrome, un proyecto secreto de Google que permite ejecutar Chrome OS sobre Android 

Posted on by

FerroChrome: ejectuando Chromiu OS sobre Android

Hace pocos días se dio a conocer la noticia de que en un evento cerrado, Google realizo la presentación del proyecto «FerroChrome» a sus socios. Este es un proyecto en el cual ha estado trabajando para poder ejecutar una versión especial del sistema operativo Chromium OS en una máquina virtual en dispositivos Android.

Y es que el gigante tecnológico ha estado llevando a cabo pruebas que involucran la ejecución de una versión especializada de Chromium OS y durante la demostración, Google presento a sus socios la interfaz de Chromium OS en una pantalla grande conectada a un Pixel 8.

La ejecución de Chromium OS en una máquina virtual se debe a que a partir de Android 13, la plataforma cuenta con «Android Virtualization Framework» (AVF), el cual está implementado sobre la base del hipervisor KVM y crosvm. Esto permite ejecutar máquinas virtuales con otros sistemas operativos y hasta ahora, Google ha utilizado AVF para realizar compilaciones de «microdroides», utilizados para aislar componentes del sistema de terceros. A finales de abril, AVF documentó la capacidad de ejecutar sistemas operativos con una interfaz gráfica de usuario y anunció soporte para la creación de sistemas invitados con Chromium OS.

Cabe mencionar que esto no es algo nuevo, ya que en su momento Samsung presento su proyecto «Samsung DeX» o incluso Ubuntu intento hacer de Ubuntu Touch un sistema que tuviera esa convergencia al ser una solución tanto para móviles, como para tareas de escritorio. Incluso se han presentado launchers que prometen ofrecer una experiencia de escritorio, pero aunque logren ofrecer esto, en el lado de las aplicaciones el tema era otro.

Es por ello que si Google logra implementar con éxito Chrome OS en Android, podría cambiar las expectativas de los usuarios en cuanto a los modos de escritorio móvil, potencialmente afectando la cuota de mercado y la popularidad de soluciones como Samsung DeX.

Sin embargo, aún es muy pronto para decir si el ambicioso proyecto de Google de llevar el uso de móviles a un nuevo nivel está en camino hacia una integración perfecta, ya que se encuentra en sus etapas iniciales.

Entre las ventajas que se mencionan de «FerroChrome» se incluye el potencial para aumentar la productividad al proporcionar una experiencia de escritorio completa en dispositivos móviles, aprovechando el poder de Chrome OS y sus capacidades, así como la conveniencia de llevar un solo dispositivo para las necesidades de computación móvil y de escritorio.

En cuanto a las posibles desventajas que podrían implicar esto, se mencionan los problemas de rendimiento debido a la ejecución de una máquina virtual en un dispositivo móvil, un posible aumento del consumo de batería y el riesgo de crear una experiencia de usuario fragmentada si no se ejecuta de manera adecuada.

Se menciona que Sameer Samat, presidente del ecosistema Android, y Dave Burke, vicepresidente de ingeniería de Android, brindaron el contexto de FerroChrome y explicaron que:

El proyecto nació de los esfuerzos continuos de Google para mejorar la seguridad de Android moviendo código confidencial desde TrustZone, un enclave seguro en CPU ARM, a máquinas virtuales. El marco de virtualización actualizado de Android 15 , con soporte para sistemas operativos gráficos y aceleración de GPU, brindó la oportunidad perfecta para probar esta nueva capacidad.

Burke mencionó:

«Necesitábamos una demostración, ¿y qué sería realmente genial? Pongamos Chrome OS ahí, ¡eso sería muy divertido! ¿Podría funcionar realmente? ¡Y funciona! Pero eso es todo. Es un demostración técnica.» Samat se hizo eco de este sentimiento y señaló que Ferrochrome era un «desafío realmente interesante» para el equipo al ampliar los límites de la nueva tecnología de virtualización.

Finalmente, cabe mencionar que, aunque la compilación de FerroChrome aún no se distribuye públicamente, pero Google ya ha publicado instrucciones para crear un sistema invitado con Chromium OS y ejecutarlo en la máquina virtual AVF. Siguiendo estas instrucciones, los entusiastas pudieron reproducir el lanzamiento de Chromium OS en un teléfono inteligente Pixel 7 Pro con un teclado y un mouse conectados.

Se espera que la capacidad de ejecutar Chromium OS permita crear un entorno de escritorio completo cuando el teléfono inteligente esté conectado a un monitor, teclado y ratón. Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/6Fnpu3Q
via IFTTT

Why Your Wi-Fi Router Doubles as an Apple AirTag

Posted on by

Image: Shutterstock.

Apple and the satellite-based broadband service Starlink each recently took steps to address new research into the potential security and privacy implications of how their services geo-locate devices. Researchers from the University of Maryland say they relied on publicly available data from Apple to track the location of billions of devices globally — including non-Apple devices like Starlink systems — and found they could use this data to monitor the destruction of Gaza, as well as the movements and in many cases identities of Russian and Ukrainian troops.

At issue is the way that Apple collects and publicly shares information about the precise location of all Wi-Fi access points seen by its devices. Apple collects this location data to give Apple devices a crowdsourced, low-power alternative to constantly requesting global positioning system (GPS) coordinates.

Both Apple and Google operate their own Wi-Fi-based Positioning Systems (WPS) that obtain certain hardware identifiers from all wireless access points that come within range of their mobile devices. Both record the Media Access Control (MAC) address that a Wi-FI access point uses, known as a Basic Service Set Identifier or BSSID.

Periodically, Apple and Google mobile devices will forward their locations — by querying GPS and/or by using cellular towers as landmarks — along with any nearby BSSIDs. This combination of data allows Apple and Google devices to figure out where they are within a few feet or meters, and it’s what allows your mobile phone to continue displaying your planned route even when the device can’t get a fix on GPS.

With Google’s WPS, a wireless device submits a list of nearby Wi-Fi access point BSSIDs and their signal strengths — via an application programming interface (API) request to Google — whose WPS responds with the device’s computed position. Google’s WPS requires at least two BSSIDs to calculate a device’s approximate position.

Apple’s WPS also accepts a list of nearby BSSIDs, but instead of computing the device’s location based off the set of observed access points and their received signal strengths and then reporting that result to the user, Apple’s API will return return the geolocations of up to 400 hundred more BSSIDs that are nearby the one requested. It then uses approximately eight of those BSSIDs to work out the user’s location based on known landmarks.

In essence, Google’s WPS computes the user’s location and shares it with the device. Apple’s WPS gives its devices a large enough amount of data about the location of known access points in the area that the devices can do that estimation on their own.

That’s according to two researchers at the University of Maryland, who said they theorized they could use the verbosity of Apple’s API to map the movement of individual devices into and out of virtually any defined area of the world. The UMD pair said they spent a month early in their research continuously querying the API, asking it for the location of more than a billion BSSIDs generated at random.

They learned that while only about three million of those randomly generated BSSIDs were known to Apple’s Wi-Fi geolocation API, Apple also returned an additional 488 million BSSID locations already stored in its WPS from other lookups.

UMD Associate Professor David Levin and Ph.D student Erik Rye found they could mostly avoid requesting unallocated BSSIDs by consulting the list of BSSID ranges assigned to specific device manufacturers. That list is maintained by the Institute of Electrical and Electronics Engineers (IEEE), which is also sponsoring the privacy and security conference where Rye is slated to present the UMD research later today.

Plotting the locations returned by Apple’s WPS between November 2022 and November 2023, Levin and Rye saw they had a near global view of the locations tied to more than two billion Wi-Fi access points. The map showed geolocated access points in nearly every corner of the globe, apart from almost the entirety of China, vast stretches of desert wilderness in central Australia and Africa, and deep in the rainforests of South America.

A “heatmap” of BSSIDs the UMD team said they discovered by guessing randomly at BSSIDs.

The researchers said that by zeroing in on or “geofencing” other smaller regions indexed by Apple’s location API, they could monitor how Wi-Fi access points moved over time. Why might that be a big deal? They found that by geofencing active conflict zones in Ukraine, they were able to determine the location and movement of Starlink devices used by both Ukrainian and Russian forces.

The reason they were able to do that is that each Starlink terminal — the dish and associated hardware that allows a Starlink customer to receive Internet service from a constellation of orbiting Starlink satellites — includes its own Wi-Fi access point, whose location is going to be automatically indexed by any nearby Apple devices that have location services enabled.

A heatmap of Starlink routers in Ukraine. Image: UMD.

The University of Maryland team geo-fenced various conflict zones in Ukraine, and identified at least 3,722 Starlink terminals geolocated in Ukraine.

“We find what appear to be personal devices being brought by military personnel into war zones, exposing pre-deployment sites and military positions,” the researchers wrote. “Our results also show individuals who have left Ukraine to a wide range of countries, validating public reports of where Ukrainian refugees have resettled.”

In an interview with KrebsOnSecurity, the UMD team said they found that in addition to exposing Russian troop pre-deployment sites, the location data made it easy to see where devices in contested regions originated from.

“This includes residential addresses throughout the world,” Levin said. “We even believe we can identify people who have joined the Ukraine Foreign Legion.”

A simplified map of where BSSIDs that enter the Donbas and Crimea regions of Ukraine originate. Image: UMD.

Levin and Rye said they shared their findings with Starlink in March 2024, which said it began shipping software updates in 2023 that force Starlink access points to randomize their BSSIDs.

Starlink’s parent SpaceX did not respond to requests for comment. But the researchers shared a graphic they said was created from their Starlink BSSID monitoring data, which shows that just in the past month there was a substantial drop in the number of Starlink devices that were geo-locatable using Apple’s API.

UMD researchers shared this graphic, which shows their ability to monitor the location and movement of Starlink devices by BSSID dropped precipitously in the past month.

They also shared a written statement they received from Starlink, which acknowledged that Starlink User Terminal routers originally used a static BSSID/MAC:

“In early 2023 a software update was released that randomized the main router BSSID,” the statement reads. “Subsequent software releases have included randomization of the BSSID of WiFi repeaters associated with the main router. Software updates that include the repeater randomization functionality are currently being deployed fleet-wide on a region-by-region basis. We believe the data outlined in your paper is based on Starlink main routers and or repeaters that were queried prior to receiving these randomization updates.”

The researchers also focused their geofencing on the Israel-Hamas war in Gaza, and were able to track the migration and disappearance of devices throughout the Gaza Strip as Israeli forces cut power to the country and bombing campaigns knocked out key infrastructure.

“As time progressed, the number of Gazan BSSIDs that are geolocatable continued to decline,” they wrote. “By the end of the month, only 28% of the original BSSIDs were still found in the Apple WPS.”

Apple did not respond to requests for comment. But in late March 2024, Apple quietly tweaked its privacy policy, allowing people to opt out of having the location of their wireless access points collected and shared by Apple — by appending “_nomap” to the end of the Wi-Fi access point’s name (SSID).

Apple updated its privacy and location services policy in March 2024 to allow people to opt out of having their Wi-Fi access point indexed by its service, by appending “_nomap” to the network’s name.

Rye said Apple’s response addressed the most depressing aspect of their research: That there was previously no way for anyone to opt out of this data collection.

“You may not have Apple products, but if you have an access point and someone near you owns an Apple device, your BSSID will be in [Apple’s] database,” he said. “What’s important to note here is that every access point is being tracked, without opting in, whether they run an Apple device or not. Only after we disclosed this to Apple have they added the ability for people to opt out.”

The researchers said they hope Apple will consider additional safeguards, such as proactive ways to limit abuses of its location API.

“It’s a good first step,” Levin said of Apple’s privacy update in March. “But this data represents a really serious privacy vulnerability. I would hope Apple would put further restrictions on the use of its API, like rate-limiting these queries to keep people from accumulating massive amounts of data like we did.”

The UMD researchers said they omitted certain details from their research to protect the users they were able to track, noting that the methods they used could present risks for those fleeing abusive relationships or stalkers.

“We observe routers move between cities and countries, potentially representing their owner’s relocation or a business transaction between an old and new owner,” they wrote. “While there is not necessarily a 1-to-1 relationship between Wi-Fi routers and users, home routers typically only have several. If these users are vulnerable populations, such as those fleeing intimate partner violence or a stalker, their router simply being online can disclose their new location.”

The researchers said Wi-Fi access points that can be created using a mobile device’s built-in cellular modem do not create a location privacy risk for their users because mobile phone hotspots will choose a random BSSID when activated.

“Modern Android and iOS devices will choose a random BSSID when you go into hotspot mode,” he said. “Hotspots are already implementing the strongest recommendations for privacy protections. It’s other types of devices that don’t do that.”

For example, they discovered that certain commonly used travel routers compound the potential privacy risks.

“Because travel routers are frequently used on campers or boats, we see a significant number of them move between campgrounds, RV parks, and marinas,” the UMD duo wrote. “They are used by vacationers who move between residential dwellings and hotels. We have evidence of their use by military members as they deploy from their homes and bases to war zones.”

A copy of the UMD research is available here (PDF).

from Krebs on Security https://ift.tt/o902VxN
via IFTTT