CHERIoT, una opcion de MS para la seguridad para sistemas integrados

Hace poco se dio a conocer la noticia de que, Microsoft ha abierto los desarrollos relacionados con el proyecto CHERIoT (Capability Hardware Extension to RISC-V for Internet of Things), destinado a bloquear problemas de seguridad en código C y C++ existente. CHERIoT ofrece una solución para proteger las bases de código C/C++ existentes sin tener que refactorizarlas.

La protección se implementa mediante el uso de un compilador modificado que usa un conjunto extendido especial de instrucciones de procesador (ISA) proporcionado por el procesador y monitorea el acceso a la memoria a nivel de hardware, verifica la corrección del trabajo con punteros y proporciona aislamiento de bloques de código.

Sobre CHERIoT

El proyecto se creó con el entendimiento de que la naturaleza de bajo nivel del lenguaje C se convierte en una fuente de errores de memoria, lo que genera problemas como desbordamientos de búfer, acceso a memoria ya liberada, desreferenciación de punteros o liberación doble.

La práctica muestra que incluso las grandes corporaciones como Google y Microsoft, que tienen una política estricta de revisión de cambios y utilizan métodos de desarrollo modernos y herramientas de análisis estático, no pueden garantizar la ausencia de errores al trabajar con la memoria (por ejemplo, alrededor del 70 % de las vulnerabilidades en Microsoft y Google son causados ​​por el manejo inseguro de la memoria).

El problema se puede resolver mediante el uso de lenguajes de programación que garanticen un trabajo seguro con la memoria o enlaces con controles adicionales, por ejemplo, mediante el uso de MiraclePtr (raw_ptr) en lugar de punteros comunes, que realiza controles adicionales para acceder a las áreas de memoria liberadas.

Pero tales métodos son más adecuados para código nuevo y es bastante problemático volver a trabajar en proyectos C/C++ existentes, especialmente si están destinados a ejecutarse en entornos con recursos limitados, como sistemas integrados y dispositivos IoT.

Los componentes de hardware de CHERIoT están diseñados como un microcontrolador basado en la arquitectura RISC-V, implementando la arquitectura de procesador segura CHERI (Extensión de hardware de capacidad para RISC-V), proporcionando un modelo de acceso a memoria controlado.

Basado en la arquitectura del conjunto de instrucciones (ISA) proporcionada en CHERIoT, se construye un modelo de programación que garantiza la seguridad de trabajar con la memoria a nivel de objetos individuales, brinda protección contra el acceso memoria ya liberada e implementa un sistema de aislamiento ligero acceso a la memoria.

Este modelo de protección mediante programación se refleja directamente en el modelo de lenguaje C/C++, lo que permite que se use para proteger aplicaciones existentes (solo se requiere la recompilación y la ejecución en hardware compatible con ISA CHERIoT) .

La solución propuesta permite bloquear errores que causan fuera de los límites de un objeto en la memoria, no permite la sustitución de punteros (todos los punteros deben generarse a partir de punteros existentes), monitorea el acceso a la memoria después de la liberación (cualquier acceso a la memoria por un puntero incorrecto o un puntero que hace referencia a un objeto liberado genera una excepción).

Por ejemplo, el uso de CHERIoT permite, sin realizar cambios en el código, implementar la verificación automática de límites, rastrear la vida útil de las áreas de memoria y garantizar la integridad de los punteros en los componentes que procesan datos no confiables.

El proyecto incluye una especificación para una arquitectura de conjunto de instrucciones CHERIoT extendida, una implementación de referencia de una CPU RISC-V de 32 bits compatible con ISA CHERIoT y un conjunto de herramientas LLVM modificado.

Finalmente si estás interesado en poder conocer más al respecto, debes saber que los diagramas de prototipos de CPU y las descripciones de bloques de hardware en Verilog se distribuyen bajo la licencia Apache 2.0. El núcleo Ibex del proyecto lowRISC se utiliza como base para la CPU y el modelo de código CHERIoT ISA se define en el lenguaje Sail y se distribuye bajo la licencia BSD.

Adicionalmente, se propone un prototipo de sistema operativo en tiempo real CHERIoT RTOS , que brinda la capacidad de aislar compartimentos (compartment) incluso en sistemas embebidos con 256 MB de RAM.

El código CHERIoT RTOS está escrito en C++ y se distribuye bajo la licencia MIT. En forma de compartimentos, se diseñan los componentes básicos del sistema operativo, como el cargador de arranque, el programador y el sistema de asignación de memoria.

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

GTK ​​ o The GIMP Toolkit​​ es una biblioteca de componentes gráficos multiplataforma para desarrollar interfaces gráficas de usuario

Después de seis meses de desarrollo, se dio a conocer el lanzamiento de la nueva versión del kit de herramientas multiplataforma para crear una interfaz gráfica de usuario, «GTK 4.10.0».

La nueva rama de GTK 4 se está desarrollando bajo un nuevo proceso de desarrollo que intenta proporcionar a los desarrolladores de aplicaciones una API estable y compatible durante varios años, que se puede usar sin temor a que las aplicaciones deban volver a trabajarse cada seis meses debido a los cambios de API en el próximo GTK.

Principales novedades de GTK 4.10

En esta nueva versión que se presenta de GTK 4.10, se destaca que se agregaron nuevas clases GtkColorDialog, GtkFontDialog , GtkFileDialog y GtkAlertDialog con la implementación de diálogos para seleccionar colores, fuentes y archivos, mostrando alertas. Las nuevas opciones se distinguen por la transición a una API más consistente y equilibrada que funciona en modo asíncrono (GIO async). Los nuevos cuadros de diálogo hacen uso de los portales de Freedesktop (xdg-desktop-portal) siempre que sea posible y estén disponibles, que se utilizan para proporcionar acceso a los recursos del entorno del usuario desde las aplicaciones de espacio aislado.

Otra de las novedades que se destaca de la nueva versión, es que se ha agregado un nuevo backend CPDB (Common Printing Dialog Backend), que proporciona controladores genéricos para usar en los diálogos de impresión. El soporte para el backend de impresión lpr utilizado anteriormente ha quedado obsoleto.

En el widget GtkFileChooserWidget con la implementación del cuadro de diálogo abierto para seleccionar archivos en aplicaciones, se implementa el modo de presentar el contenido de los directorios en forma de una red de iconos. De forma predeterminada, se sigue utilizando la vista de lista de archivos clásica y ha aparecido un botón separado en el lado derecho del panel para cambiar al modo de icono.

La biblioteca GDK, que proporciona una capa entre GTK y el subsistema de gráficos, propone la estructura GdkTextureDownloader , que se usa para cargar texturas en la clase GdkTexture y se puede usar para convertir varios formatos, se ha mejorado el escalado de textura usando OpenGL.

Ademas de ello, la biblioteca GSK (GTK Scene Kit), que brinda la capacidad de renderizar escenas gráficas a través de OpenGL y Vulkan, admite nodos con máscaras y filtrado personalizado de texturas escalables.

Tambien se destaca que se ha implementado el soporte para nuevas versiones de las extensiones del protocolo Wayland, pues la salida fue mejorada en las notificaciones de inicio cuando se utiliza el protocolo «xdg-activation» y que se resolvieron problemas con el tamaño del cursor en pantallas con alta densidad de píxeles.

De los demás cambios que se destacan de la nueva versión:

• La clase GtkMountOperation se ha adaptado para trabajar en entornos que no sean X11.
• Se agregó soporte para ventanas modales al backend de Broadway, lo que le permite dibujar la salida de la biblioteca GTK en una ventana del navegador web
• La clase GtkFileLauncher propone una nueva API asíncrona para reemplazar gtk_show_uri
• Manejo mejorado de plantillas en gtk-builder-tool.
• El widget GtkSearchEntry ha agregado soporte para que se muestre texto de relleno cuando el campo está vacío y no hay foco de entrada.
• La clase GtkUriLauncher se agregó para reemplazar la función gtk_show_uri , que se usa para determinar qué aplicación iniciar para mostrar un URI determinado o para generar un error si no hay un controlador presente
• En la clase GtkStringSorter , se ha agregado soporte para varios métodos de «intercalacion» que permiten la intercalación y clasificación según el significado de los caracteres (por ejemplo, si hay un signo de acento).
• Una gran parte de las API y los widgets han quedado en desuso, que se decidió no admitir en la futura rama GTK5 y que se reemplazaron con análogos que funcionan en modo asíncrono
• Transferido a la interfaz pública GtkAccessible , que le permite conectar controladores de elementos de interfaz de terceros para personas con discapacidades. Se agregó la interfaz GtkAccessibleRange .
• En macOS, se proporciona soporte para arrastrar y soltar (DND, Drag-and-Drop).
• En Windows, se ha mejorado la integración con la configuración del sistema.
• Formato de salida de depuración unificado.
• El límite de memoria para el cargador de imágenes JPEG se elevó a 1 GB.

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/boGAJtc
via IFTTT

Nitrux continua con la migración hacia Maui Shell

Se dio a conocer hace poco el lanzamiento de la nueva versión de la distribución de Linux, «Nitrux 2.7.0», la cual su principal novedad es la introduccion de una nueva imagen del sistema construida con Maui Shell, actualizaciones y más.

Para quienes desconocen de esta distribución, deben saber que está construida sobre la base del paquete Debian, las tecnologías KDE y el sistema de inicio OpenRC. Esta distribución se destaca por el desarrollo de su propio escritorio «NX», que es un complemento sobre el entorno KDE Plasma del usuario, además de que el proceso de instalación de aplicaciones está basado en el uso de paquetes AppImages.

El escritorio NX ofrece un estilo diferente, su propia implementación de la bandeja del sistema, el centro de notificaciones y varios plasmoides, como un configurador de conexión de red y un subprograma multimedia para control de volumen y control de reproducción de medios.

Entre las aplicaciones creadas con el marco MauiKit, se puede mencionar el administrador de archivos Index (también se puede usar Dolphin), el editor de texto Note, el emulador de terminal Station, el reproductor de música VVave, el reproductor de video Clip, el control de aplicaciones NX Software Center center y el visor de imágenes Pix.

El entorno de usuario de Maui Shell está evolucionando en torno al concepto de «Convergencia», lo que significa que las mismas aplicaciones se pueden usar en pantallas táctiles de teléfonos inteligentes y tabletas, así como en pantallas grandes de computadoras portátiles y PC.

Principales novedades de Nitrux 2.7

En esta nueva versión que se presenta de Nitrux 2.7, podremos encontrar que los componentes de NX Desktop se han actualizado a KDE Plasma 5.27.2, KDE Frameworks 5.103.0 y KDE Gear (KDE Applications) 22.12.3.

Mientras que por la parte de las versiones de software actualizadas, los paquetes que se destacan son las actualizaciones que incluyen Mesa 23.1-git, Firefox 110.0.1 y controladores NVIDIA 525.89.02.

Otro de los cambios que se destaca de esta nueva versión, es que de forma predeterminada, el kernel de Linux 6.1.15 con parches de Liquorix está habilitado.

Ademas de ello, tambien se menciona que esta nueva versión la composición incluye los paquetes con OpenVPN y open-iscsi, asi como tambien que se eliminaron los archivos ejecutables con las utilidades de administración de paquetes de la imagen en vivo (el instalador de Calamares puede instalar el sistema y ellos, y son superfluos en una imagen en vivo estática).

El Centro de software NX se ha reconstruido con MauiKit, ademas de que se ha comenzado con la formación de una imagen ISO separada con Maui Shell, la cual cuenta con las versiones actualizadas de MauiKit 2.2.2, MauiKit Frameworks 2.2.2, Maui Apps 2.2.2 y Maui Shell 0.6.0.

Esta nueva compilación ofrecida todavía está posicionada para demostrar las capacidades del nuevo shell y las aplicaciones disponibles. El programa incluye Agenda, Arca, Bonsai, Booth, Buho, Clip, Communicator, Fiery, Index, Maui Manager, Nota, Pix, Shelf, Station, Strike y VVave.

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

Descargar la nueva versión de Nitrux

Si quieren descargar esta nueva versión de Nitrux 2.6, deberán de dirigirse a la página web oficial del proyecto en donde podrán obtener el enlace de descarga de la imagen del sistema y la cual podrán grabar en un USB con ayuda de Etcher. Nitrux está disponible para su descarga inmediata desde el siguiente enlace. El tamaño completo de la imagen de arranque es de 3,2 GB (NX Desktop) y 2,6 GB (Maui Shell).

Para aquellos que ya se encuentran sobre una versión anterior de la distribución, pueden hacer la actualización a la nueva versión, tecleando los siguientes comandos:

sudo apt update

sudo apt install --only-upgrade nitrux-repositories-config amdgpu-firmware-extra

sudo apt install -o Dpkg::Options::="--force-overwrite" linux-firmware/trixie

sudo apt dist-upgrade

sudo apt autoremove

sudo reboot

En cuanto a los que cuentan con una versión anterior de la distribución, pueden realizar la actualización del Kernel tecleando alguno de los siguientes comandos:

sudo apt install linux-image-mainline-lts
sudo apt install linux-image-mainline-current

Para los que estén interesados en poder instalar o probar los kernels Liquorix y Xanmod:

sudo apt install linux-image-liquorix
sudo apt install linux-image-xanmod-edge
sudo apt install linux-image-xanmod-lts

Finalmente para los que prefieren el uso de los kernels Linux Libre LTS y no LTS más recientes:

sudo apt instalar linux-image-libre-lts
sudo apt instalar linux-image-libre-curren

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

El problema del año 2038 podría causar que una parte del software falle en ese año. El problema afecta a los programas que usen la representación del tiempo basada en el sistema POSIX

Thorsten Kukuk, líder del Equipo de Future Technology de SUSE (Equipo de tecnología futura, desarrolla openSUSE MicroOS y SLE Micr ), quien anteriormente dirigió el proyecto SUSE LINUX Enterprise Server durante 10 años, sugirió deshacerse del archivo /var/run/utmp en distribuciones para abordar completamente el problema Y2038 en Glibc.

Con ello se propone mover todas las aplicaciones que usan utmp, wtmp y lastlog para obtener una lista de usuarios que usan systemd-logind.

El 19 de enero de 2038, se desbordarán los contadores de tiempo de época especificados por el tipo time_t de 32 bits. En Glibc, a pesar de la introducción del tipo time_t de 64 bits, para mantener la compatibilidad con aplicaciones de espacio de usuario de 32 bits, el tipo time_t de 32 bits todavía se usa en algunos casos en plataformas de 64 bits.

Hay dos problemas principales con utmp/utmpx con glibc en, por ejemplo, x86-64:

Se utiliza un campo time_t de 32 bits para la hora, que se desbordará en 2038
Hay problemas de diseño que permiten un ataque DoS ( el bloqueo de utmp/wtmp permite que un usuario sin privilegios niegue el servicio )
Un análisis del segundo problema por parte de los desarrolladores de glibc mostró que sería necesario un demonio adicional que maneje el acceso utmp/utmpx.

Aun que hay algunos problemas más…

Uno de esos casos es el archivo /var/run/utmp, que almacena datos sobre los usuarios actualmente conectados al sistema. El campo de tiempo en utmp se establece utilizando un valor time_t de 32 bits.

Se menciona que, simplemente cambiar un campo en utmp con el tiempo de un tipo de 32 bits a uno de 64 bits no funcionará, ya que esto cambiará la Glibc ABI (el tipo cambiará en funciones como login(), getutid() y utmpname()) y rompa la compatibilidad con aplicaciones que usan utmp, incluidas w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc.

Debido a la abundancia de posibles escollos y laboriosidad, los desarrolladores de Glibc rechazaron la idea de reemplazar la longitud de bits del tipo time_t en utmp. Por la misma razón, se eliminó la opción de usar el espacio disponible en la estructura utmp para agregar un campo de tiempo adicional de 64 bits.

Además, cambiar la profundidad de bits del tipo en utmp no resuelve otros problemas existentes, por ejemplo, escribir en utmp requiere permisos especiales, lo que requiere que se otorguen privilegios adicionales a los procesos. Otro problema es que la arquitectura utmp permite a los usuarios locales realizar ataques DoS que rompen el servicio utmp mediante la manipulación de bloqueos de archivos, lo que hace imposible estar seguro de que el contenido de utmp refleje el estado real del sistema.

Se propuso usar un proceso en segundo plano adicional para manejar el acceso a utmp, pero para tales tareas ya existe un proceso systemd-logind y no es recomendable iniciar otro proceso especializado (las aplicaciones tendrán que transferir datos a dos controladores al mismo tiempo).

Al mismo tiempo, incluso al resolver el problema con los ataques DoS, el contenido de utmp sigue siendo solo informativo, sin garantizar un reflejo de la realidad.

Por ejemplo, diferentes emuladores de terminales y multiplexores reflejan su estado de manera diferente: ejecutar cinco terminales GNOME dará como resultado que un usuario se refleje en utmp, mientras que ejecutar cinco terminales konsole o xterm en KDE dará como resultado seis. Del mismo modo, el comportamiento de screen y tmux difiere, en el primer caso cada sesión se cuenta como un usuario independiente y en el segundo solo se refleja un usuario para todas las sesiones.

Como resultado, como la solución más simple, se propone transferir todas las aplicaciones para usar el servicio systemd-logind alternativo ya existente y, después de que no haya programas reales que accedan a utmp, dejar de escribir en utmp. Para reemplazar wtmp, se propone preparar API para escribir y leer información sobre los usuarios que usan systemd-journald.

Finalmente, cabe mencionar que la base de código para la próxima versión de systemd 254 ya incluye las funciones necesarias para proporcionar datos utmp de reemplazo a través de libsystemd usando la API sd-login.h o a través de DBUS.

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/107X9p3
via IFTTT