La entrada Akademy 2023 Plasma 6 is coming se publicó primero en KDE Blog.

Se están publicando los vídeo del último gran evento comunitario de KDE. En este encuentro se presentaron muchos proyectos pero quizás el más esperado por los usuarios de calle sea esta charla titulada «Akademy 2023 Plasma 6 is coming» en la que Niccolò Venerandi y Marco Martin nos cuentan el estado de desarrollo de Plasma 6. ¿Te interesa? Sigue leyendo.

Akademy 2023 Plasma 6 is coming – Vídeo

No poder ir a un evento Akademy 2023 de Teselónica ya no significa no enterarse de las cosas. Afortunadamente tenemos vídeos como el siguiente donde los desarrolladores nos cuentan interesantes detalles sobre un proyecto que, si eres lector del blog, nos apasiona: el futuro escritorio Plasma 6.

En palabras del canal de youtube de «The KDE Community» nos encontramos ante una charla que nos contará que:

Plasma está siendo portado también a Qt6 y KF6. Algunas cosas cambiarán, otras se mantendrán más «estables». Esta charla repasará lo que esto significará para el usuario final, pero también lo que significará para el desarrollador.
Se presentará la visión VDG para la experiencia del usuario, el estado actual de las cosas y lo que va a cambiar para el autor plasmoide, lo que es diferente en la API y por qué

Entre las cosas que destaca Niccolò Venerandi, miembro de KVDG (KDE Visual Design Gropp), en laparte visual) tenemos:

• Completo rediseño visual que se adapta a todo tipo de dispositivos mejor que en la anterior versión.
• 100% compatible con pantalla táctiles y con gestos.
• Completo rediseño del panel de configuración.
• Renovados los paneles flotantes, tanto que ahora serán los paneles por defecto.
• Renovado el diseño de los plasmoides (también conocidos como applets o widgets)
• Rediseñado el intercambiador de tareas.
• Ventanas de diálogo flotantes.
• Rediseñado el tema de iconos para Lugares.
• Rediseñado el tema de cursores.
• Rediseñado el tema de sonidos.
• Cabeceras de ventanas completamente coloreadas.

Por su parte, Marco Martin habló de la parte técnica la cual frecerá) nos encontramos novedades como las siguientes:

• Soporte para HDR.
• Composite restarts, lo que significa que aunque el compositor de ventanas Wayland se rompa las aplicaciones se mantendrán.
• Nuevo soporte para espacios de trabajo y/o actividades.
• Rediseño plasmoides, incluído su API.
• Añadida una nueva librería llamada KSvg que ayudará a los desarrolladores a utilizar los gráficos vectoriales.
• Mejoras en Kirigami que lo hacen más versátil (colores, unidades, iconos, etc.)

Como vemos, toneladas de novedades que esperamos que lleguen lo bastante estable el próximo 28 de febrero de 2024, fecha de lanzamiento de Plasma 6.

La entrada Akademy 2023 Plasma 6 is coming – Vídeo se publicó primero en KDE Blog.

Sigo con estas pequeñas aplicaciones que se conocen como applets, widgets o plasmoides y que dotan de funcionalidades de todo tipo a nuestro entorno de trabajo KDE yqi¡ue parece que van a sufrir un lavado de cara considerable en Plasma 6. Hoy toca un plasmoide llamado Bubble Date, una forma original de visualizar la fecha en KDE , que será el plasmoide número 230 de la serie.

Bubble Date, una forma original de visualizar la fecha en KDE – Plasmoides de KDE (230)

Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.

Así que espero que le deis la bienvenida a un plasmoide llamado Bubble Date, , una creación de Zayronxyo con el que visualizas la fecha (día, día de la semana y mes) de una forma original en tu esritorio. Un plasmoide simple pero que está destinado a protagonizar muchos viernes de escritorio por su estilo diferenciado, como podemos ver en la imagen inferior.

Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecer?: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

La entrada Bubble Date, una forma original de visualizar la fecha en KDE – Plasmoides de KDE (230) se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2023/10/opensuse-tumbleweed-review-of-the-week-2023-43/

Una semana más cargada de instantáneas de Tumbleweed llega a su fin. Esta semana, entregamos cinco instantáneas (y una nueva ya está en openQA).

Las 5 snapshots (1019, 1020, 1022, 1023, y 1025) han traido entre otros, estos cambios:

• KDE Frameworks 5.111.0
• KDE Plasma 5.27.9
• Samba 4.19.2
• SQLite 3.43.2
• Apache 2.4.58
• Linux kernel 6.5.8
• Pipewire 0.3.83
• Virtualbox 7.0.12
• zlib 1.3
• Redis 7.2.2
• Meson 1.2.3

Y muchas cosas que ya se están preparando para próximas snapshots:

• Qemu 8.1.2
• VLC 3.0.19
• LLVM 17.0.3
• Boost 1.83.0
• Linux kernel 6.5.9
• openSSL 3.1.4
• PHP 8.2.12
• binutils 2.41
• moving to dbus-broker

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

Another week fully loaded with Tumbleweed snapshot comes to an end. This week, we have delivered five snapshots (with a new one already in openQA).

The five snapshots (1019, 1020, 1022, 1023, and 1025) brought you those changes:

• KDE Frameworks 5.111.0
• KDE Plasma 5.27.9
• Samba 4.19.2
• SQLite 3.43.2
• Apache 2.4.58
• Linux kernel 6.5.8
• Pipewire 0.3.83
• Virtualbox 7.0.12
• zlib 1.3
• Redis 7.2.2
• Meson 1.2.3

And, as after the snapshot is before the snapshot, the subsequent things are already lined up and getting ready to reach you. The most intriguing things there are:

• Qemu 8.1.2
• VLC 3.0.19
• LLVM 17.0.3
• systemd: Ship the main configuration files in /usr/lib/; this change will hopefully encourage users to customize the defaults via drop-ins, hence removing the risk of conflicts with downstream customization.
• Boost 1.83.0
• Linux kernel 6.5.9
• openSSL 3.1.4
• PHP 8.2.12
• binutils 2.41
• moving to dbus-broker

This is a report about findings in the Passim local caching server.

1) Introduction

Passim is a relatively new project for a local caching server that helps distributing publicly available files in local networks to save network bandwidth. It is a dependency of new fwupd releases, which is why it has come to our attention.

Passim consists of a daemon component running as a separate passim user and group. The daemon offers a local D-Bus interface over which only the root user may publish or unpublish files on the network. Non-root users may only inspect the available items via D-Bus.

Furthermore the daemon announces all cached items via the Ahavi discovery protocol. For retrieval of individual items a small libsoup based HTTP server is integrated into the daemon, listening on port 25000.

A small command line programm passim allows to interact with the daemon’s D-Bus interface.

The findings in this report are based on the upstream release tag 0.1.3.

2) Findings

2.1) Remote DoS Against passimd by Triggering NULL Pointer Dereference

When accessing a URL different from the root “/” and without passing any parameters “?” then a segmentation fault is the result in passim-server.c:751 (null pointer dereference, because there is no request).

Example:

root# curl -v -k 'https://localhost:27500/myfile'
root# journalctl -u passim.service | tail -n 5
Oct 25 12:45:24 mybox passimd[5091]: accepting HTTP/1.1 GET /myfile  from ::1:39278 (loopback)
Oct 25 12:45:24 mybox passimd[5091]: g_strsplit: assertion 'string != NULL' failed
Oct 25 12:45:29 mybox systemd[1]: passim.service: Main process exited, code=dumped, status=11/SEGV
Oct 25 12:45:29 mybox systemd[1]: passim.service: Failed with result 'core-dump'.

Upstream has library settings in effect to abort on failing assertions instead of trying to continue, to prevent possible memory access errors from becoming exploitable.

This issue is fixed via upstream commit 1f7bcea.

2.2) Serving Static Files from a Directory owned by Unprivileged Users

Passim supports the configuration of static directories on the local file system, whose content will be processed and published upon startup.

Consider a directory controlled by ‘nobody’:

root# cat /etc/passim.d/nobody.conf
[passim]
Path=/var/lib/nobody/passim

There’s two things that I found problematic in such a scenario.

a) Placing Inaccessible Files in the Directory

root# sudo -u nobody -g nobody /bin/bash
nobody$ mkdir /var/lib/nobody/passim
nobody$ touch /var/lib/nobody/passim/somefile
nobody$ chmod 000 /var/lib/nobody/passim/somefile

This will prevent future starts of passimd:

root# systemctl restart passim.service
Job for passim.service failed because the control process exited with error code.
See "systemctl status passim.service" and "journalctl -xeu passim.service" for details.
root# journalctl -u passim.service | tail -n 6
Oct 25 12:56:58 mybox passimd[5330]: scanning /var/lib/nobody/passim
Oct 25 12:56:58 mybox passimd[5330]: failed to scan sysconfpkg directory: Error opening file /var/lib/nobody/passim/somefile: Permission denied
Oct 25 12:56:58 mybox systemd[1]: passim.service: Main process exited, code=exited, status=1/FAILURE
Oct 25 12:56:58 mybox systemd[1]: passim.service: Failed with result 'exit-code'.
Oct 25 12:56:58 mybox systemd[1]: Failed to start Local Caching Server.

This opens a local DoS attack vector against passimd for the unprivileged user that owns the directory. This is also valid for other situations like a FIFO placed there, broken symlinks or symlinks to inaccessible locations as well as race conditions (time of readdir() vs. time of open()).

This has at least partially been addressed by upstream commit f4c34bd3.

b) Placing Symlinks to Otherwise Inaccessible Data in the Directory

Although passimd runs with low privileges by default there are some interesting files that a local attacker might want to get their hands on. Since passimd follows symlinks in this directory one could try to “publish” files from /proc/<pidof passimd> by placing symlinks. This is somewhat difficult though, since a race condition has to be won (the PID of a starting passimd needs to be known to place a proper symlink). Also there are not that many interesting files in there I believe. Also e.g. /proc/<pid>/mem cannot be shared this way, since it cannot be read sequentially.

A much simpler attack is to publish the SSL private key of passimd though:

root# sudo -u nobody -g nobody /bin/bash
nobody$ mkdir /var/lib/nobody/passim
nobody$ ln -s /var/lib/passim/secret.key /var/lib/nobody/passim/secret

root# systemctl restart passim.service
root# passim dump
passimd is running
1c69e7e4d7b7ed655eafa94942a5ef04f7c7688a0519be387133176154f58fe6 secret size:2.5 kB

root# sha256sum /var/lib/passim/secret.key
1c69e7e4d7b7ed655eafa94942a5ef04f7c7688a0519be387133176154f58fe6  /var/lib/passim/secret.key

From here on the local attacker can simply download the now shared “secret key” from localhost.

It has to be noted that this SSL private key has no security purpose in passimd but only serves to prevent network traffic security scanners from raising alarm over unencrypted traffic.

Thus currently there is no known information leak using this attack that has attacker value. It is still crossing of a security boundary and could be problematic in the future.

Upstream issue #26 deals with this issue but is not yet completely fixed, due to a remaining race condition.

Bugfix Release and Upstream Reporting

I reported these issues to the upstream author on 2023-10-25. No coordinated disclosure was desired so bugfixes have been and still are developed publicly over the GitHub issue tracker.

There are some disagreements with upstream about whether these issues are qualifying as security issues. I believe they are. Due to this no CVEs have been assigned as of now.

Passim is packaged, to my knowledge, in Fedora Linux and Arch Linux already. Otherwise it should not be widespread.

Upstream is working on a new release of Passim containing fixes for these and some other non-security issues that I reported as well.

References

• Passim GitHub repository
• Fwupd GitHub repository
• Passim Release Tag 0.1.3
• Passim NULL pointer dereference source code location
• Passim NULL pointer dereference bugfix
• Passim bugfix to be robust against EPERM errors
• Passim issue report about the possibility to leak the SSL private key

Introduction

During a routine review of the setuid-root binary vmware-user-suid-wrapper from the open-vm-tools repository I discovered the vulnerability described in this report. The version under review was open-vm-tools version 12.2.0. The setuid-root binary’s source code in the open-vm-tools repository did not change since version 10.3.0 (released in 2018), however, so likely most current installations of open-vm-tools are affected by this finding.

Behaviour of vmware-user-suid-wrapper

On first look the vmware-user-suid-wrapper seems to be small and harmless:

• it opens /dev/uinput as root, if it believes to be running on Wayland. The latter is determined by inspecting the value of the environment variable XDG_SESSION_TYPE, checking whether it is set to “wayland”.
• it opens /var/run/vmblock-fuse/dev, if existing, as root.
• it permanently drops all privileges to the real (unprivileged) user and group ids and executes /usr/bin/vmtoolsd, inheriting to it any of the previously opened file descriptors.
• the new vmtoolsd process will inspect the environment, e.g. check whether the current host is running in a vmware guest environment and whether a graphical session is available. If one of these is not fulfilled then the process quickly terminates. On success the daemon keeps running, providing its services, keeping the privileged file descriptors open.

So it seems everything is in order, the program opens up to two privileged files, drops privileges and passes the open files on to vmtoolsd to use them in the calling user’s context.

The Vulnerability

The (somewhat surprising) problem here is the combination of dropping privileges to the real uid / gid and the following execve() to execute the non-setuid program vmtoolsd. During the execve() the process’s “dumpable” attribute is reset to the value of 1.

From the man page prctl(5) we can learn the following about a process’s dumpable attribute:

Normally, the "dumpable" attribute is set to 1. However, it is reset to
the current value contained in the file /proc/sys/fs/suid_dumpable (which by
default has the value 0), in the following circumstances:

[...]

- The process executes (execve(2)) a set-user-ID or set-group-ID program,
  resulting in a change of either the effective user ID or the effective
  group ID.

[...]

Processes that are not dumpable can not be attached via ptrace(2)
PTRACE_ATTACH; see ptrace(2) for further details.

On most Linux distributions the global suid_dumpable setting is set either to 0 (setuid programs may not dump core at all) or 2 (setuid programs may dump core but only in safe file system locations). Consequently when vmware-user-suid-wrapper runs, its dumpable attribute is set to 2 on openSUSE Tumbleweed, which I have been using while researching this issue. However after the execve() this changes, as is also documented in the execve(2) man page:

The following Linux-specific process attributes are also not preserved
during an execve():

- The process's "dumpable" attribute is set to the value 1, unless a
  set-user-ID program, a set-group-ID program, or a program with
  capabilities is being executed, [...].

Consequently when vmtoolsd is executed with dropped privileges, the process’s “dumpable” attribute will be reset to 1.

The problem with this is that the unprivileged user that originally invoked vmware-user-suid-wrapper now is allowed to ptrace() the vmtoolsd process along with a number of other operations that have not been allowed on the setuid-root process before.

The interesting resources that vmtoolsd has from a unprivileged user’s perspective are the open file descriptors for /dev/uinput and/or /var/run/vmblock-fuse/dev. With the help of ptrace() malicious code could be injected into the vmtoolsd process to get access to the privileged file descriptors. An even easier approach is to use modern Linux’s pidfd API pidfd_open() and pidfd_getfd() to obtain a copy of the privileged file descriptors. In the man page pidfd_getfd(2) we can find:

Permission to duplicate another process's file descriptor is governed by a
ptrace access mode PTRACE_MODE_ATTACH_REALCREDS check (see ptrace(2)).

In this context this again boils down to the process’s “dumpable” attribute which is now set to 1, and thus the operation is allowed.

Exploiting the Issue

vmware-user-suid-wrapper can be forced to open /dev/uinput even if not running on Wayland by setting the user controlled environment variable XDG_SESSION_TYPE=wayland. This means the file descriptor for this device file will always be a valid attacker target independently of the actual situation on a system.

There are two different scenarios to look at regarding the exploitability of the issue. The easier case is when a valid environment for vmtoolsd is available i.e. a graphical desktop session is existing and the check for running in a VMware guest machine is succeeding (function call VMCheck_IsVirtualWorld()). In this case vmtoolsd will continue running permanently and there is no race condition to be won. Exploiting the issue is straightforward, as is demonstrated in the PoC program vmware-get-fd.c.

The more difficult case is when an attacker is either not running a graphical environment or not even running in a VMware guest environment. In the worst case vmtoolsd will terminate quickly, because of the failing VMCheck_IsVirtualWorld() check. Thus the time window for actually operating on the vulnerable process is short. A variant of the PoC program, vmware-race-fd.c, starts the vmware-user-suid-wrapper continuously and attempts to snatch the privileged file descriptors from the short-lived vmtoolsd process. In my tests this often succeeded quickly (even on the first attempt), likely when the vmtoolsd resources have not yet been cached by the kernel. Later attempts often take a longer time to succeed but still succeeded after 10 to 20 seconds.

In summary the existence of the setuid-root program vmware-user-suid-wrapper is enough to exploit the issue for /dev/uinput. The attacker needs no special permissions (even the nobody user can exploit it) and the operating system doesn’t even need to be running as a VMware guest. This can be relevant in situations when open-vm-tools are distributed by default in generic Linux distributions / images, or in environments where unprivileged users are allowed to install additional software from trusted sources without root authentication (a model that is e.g. supported by the PackageKit project).

Vulnerability Impact

/dev/uinput

Getting access to a file descriptor for the /dev/uinput device allows an attacker to create arbitrary userspace based input devices and register them with the kernel. This includes the possibility to send synthesized key or mouse events to the kernel. The example program uinput-inject.c demonstrates how this can be used to cause arbitrary key strokes to be injected into local user sessions both graphical or on textual login consoles. Thus this attack vector borders the area of arbitrary code execution with the restriction that a local interactive user needs to be present.

This aspect of the vulnerability could be used to increase privileges after gaining low privilege access e.g. through a remote security hole. On multi user machines with shared access it could be used to prepare an attack where a background process waits for a victim user to log into the machine and then inject malicious input into its session.

Since /dev/uinput is not VMware specific, this attack vector is basically also available in non-VMware environments.

The following is an example exploit run using the attached programs, provided the vmware-user-suid-wrapper is already installed and a compiler is available:

user$ gcc -O2 vmware-race-fd.c -ovmware-race-fd
user$ gcc -O2 uinput-inject.c -ouinput-inject

user$ ./vmware-race-fd
vmware-user: could not open /proc/fs/vmblock/dev
vmware-user: could not open /proc/fs/vmblock/dev
[...]
/usr/bin/vmtoolsd running at 12226
Found fd 3 for /dev/uinput in /usr/bin/vmtoolsd
Executing sub shell which will inherit the snatched file descriptor 4 (check /proc/self/fd)

user$ ls -l /proc/self/fd/4
l-wx------ 1 user group 64 Jul 25 13:43 /proc/self/fd/4 -> /dev/uinput

user$ ./uinput-inject 4
Sleeping 3 seconds for input subsystem to settle
completed one iteration
completed one iteration

This will continuously write the line “you have been hacked” onto whatever session is currently selected on the system’s display.

/var/run/vmblock-fuse/dev

As far as I understand, this file is created by the vmware-vmblock-fuse daemon and represents a control file. The FUSE file system is used to implement access to folders shared between the VMware host and VMware guests. This file allows, according to documentation, to add, delete or list blocks in shared folders.

As a result access to this file descriptor breaks the boundary between different users in the guest system regarding shared folder access. The integrity of the shared folder content can be violated. It might also be possible to leak information from shared folders into the unprivileged user’s context.

Depending on the actual environment it might allow to result in code execution if e.g. malicious code is written to shared folders that could then be executed even on the VMware host system.

The vmware-fuse documentation mentions the outlook to allow unprivileged users access to this control file, but this idea seems not safe to me in its current form.

I did not look more closely into practical exploits of this.

Suggested Fix

To fix this problem it must be prevented that the “dumpable” attribute of the vmware-user-suid-wrapper process is reset when executing vmtoolsd. One way to achieve this could be to move the privilege drop logic into vmtoolsd instead. As long as the process is running in the setuid-root context, the “dumpable” attribute will not be reset. vmtoolsd can then drop privileges and also mark the privileged file descriptors with the O_CLOEXEC flag to prevent them to be inherited unintendedly to further child processes, which might result in the same problem again.

Update: This is the route that the patch provided by upstream has taken.

As a first aid and/or hardening measure, access to the vmware-user-suid-wrapper could be limited to members of a privileged group e.g. vmware-users. This would reduce the attack surface and prevent e.g. a compromised nobody user account to exploit this.

In terms of hardening, the vmware-user-suid-wrapper could also add some code to sanitize the environment variables passed from the unprivileged context, which is a frequent source of security issues in setuid-root binaries. At least the PATH variable should be reset to a safe value to avoid any future surprises when looking up executable for execve().

Timeline

References

• open-vm-tools GitHub repository
• open-vm-tools vmblock-fuse design document

Otro mes que apuro para publiar esta típica entrada. Sigo la iniciativa #viernesdeescritorio con una nueva captura, con la que llegaré a casi dos años seguidos compartiendo «Mi escritorio» de forma mensual, una mirada a la intimidad de mi entorno de trabajo. De esta forma, bienvenidos a mi escritorio Plasma de octubre 2023, el décimoprimero del año (por la ración doble de febrero) que destaca por su simplicidad.

Mi escritorio Plasma de octubre 2023 #viernesdeescritorio

Esta va a ser la cuadragésimoprimera (41 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 5 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante. Hice un recopilatorio con los 12 escritorios del 2022 y tengo pendiente seguir con otros, para finalizar con una entrada que los recopile todos… pero eso será en un futuro.

En esta ocasión sido en mi equipo de sobremesa que es el que má utilizo estas últimas semanas, un Slimbook Kymera AMD el cual tiene instalado un KDE Neon 22.04 actualizado Plasma 5.27.8 con KDE Frameworks 5.111 siendo mi sistema gráfico Waylando, dejando atrás ya (por fin) X11. Solo puedo decir que todo me funciona bien ejecutando incluso juegos por Protón, en Linux sí se puede jugar.

Sigo con el tema global Edna, del gran Jomada el cual ya ha aparecido muchas veces en el blog, aunque he vuelto a la barra clásica inferior ya que he tenido algún que otro problema con alguna que otra aplciación. He cambiado el fondo ya que me encanta este llamado Scrtachy, también de Jomada, el cual está disponible en la Store de KDE.

Los iconos son los Kora que quedan muy en temas oscuros. Respecto a plasmoides tengo solo uno: Solo Clock, un plasmoide que me muestra la hora y día en el fondo de escritorio.

El resultado de mi escritorio Plasma de octubre de 2023 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de octubre 2023 #viernesdeescritorio se publicó primero en KDE Blog.