Mientras sigo preparando la entrada recopilatoria del 2024 reaizaso la segunda de este año de la iniciativa #viernesdeescritorio. Bienvenidos a mi escritorio Plasma de febrero 2025, realizado sobre mi portátil Slimbook Pro, con el que llegamos a las 57 entregas compartiendo «Mi escritorio» de forma mensual (¿tendré la visita mensual de mi troll?).

Mi escritorio Plasma de febrero 2025 #viernesdeescritorio

Esta va a ser la quincuagésimoséptima (57 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 6 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante.

Y en esta ocasión lo realizo de nuevo sobre mi Slimbook Pro, el cual tiene instalado un KDE Neon con Plasma 6.2.0, sobre una versión de KDE Frameworks 6.6 y una versión de Qt 6.7.2 El servidor gráfico es Wayland y el Kernel es 6.8.0-49-generic (64 bits). Este fin de semana voy a dedicar un tiempo a actualizarlo, sí o sí.

Respecto al mes pasado no he realizado muchos cambios. Sigo con el tema global básico Brisa Oscuro, los iconos Deepin2022-Dark y mantengo la barra de actividades de la derecha a la izquierda ya que es más cómodo a la hora de utilizar las barras de desplazamiento y aprovechar el ancho de la pantalla.

He cambiado el reloj-calendario Modern Clock de Prayagjain bastante modificado que le queda de fábula sobre un fondo muy colorido ya que este último mes necesitaba contraste para seguir con mi gris y ajetreada vida.

El resultado de mi escritorio Plasma de febrero de 2025 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 febrero 2025 #viernesdeescritorio se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) History of Privileged File Operations in KDE
  • KTextEditor File Saving Operation
  • KIO Framework for Privileged File System Operations
  • The kio-admin Back End
  • Integration of kio-admin into the Dolphin File Manager
• 3) Assessment of Security Concerns
• 4) Rationale for Accepting kio-admin into openSUSE
• 5) Recommendations for Users of kio-admin or gvfs
• 6) Next Steps for Inclusion of kio-admin
• 7) References

1) Introduction

kio-admin is a KDE component which allows to perform privileged file operations in GUI applications. It implements a D-Bus service running as root and uses Polkit for authentication. A typical use case of kio-admin is found in KDE’s Dolphin file manager, which allows to enter an admin mode, in which file manager operations are carried out as root instead of as the unprivileged user.

The initial 2022 request to add kio-admin to openSUSE was rejected by us due to security concerns. Some time ago we have been asked to revisit this package to see if it could be added now. The security assessment of kio-admin is a difficult one, nonetheless we decided to accept it into openSUSE this time since the probability of actual exploits is low. The following sections explore the history of privileged file operations in KDE up to kio-admin, the rationale for accepting it into openSUSE at this point and recommendations for safely performing privileged file operations in complex scenarios.

2) History of Privileged File Operations in KDE

KTextEditor File Saving Operation

Historically, for performing privileged operations in GUI applications, the complete application had to be executed as root. Doing so is generally discouraged, since GUI programs are complex and not always written with potential security issues in mind. Also the inner workings of the X11 protocol and X server implementations have been a reason for security woes when running graphical applications with raised privileges.

One way out of this “all or nothing” approach was the introduction of Polkit, which allows to define individual actions for privileged operations. These actions are authenticated by the polkitd daemon. Applications are then typically separated in two parts. An unprivileged graphical application which contains the majority of the code communicates with a back end to execute the privileged operations. The back end is much smaller in size and runs as root.

This approach works well when the nature of the privileged operation has a clearly defined scope like “enable a VPN connection” or “connect to a Bluetooth device”. Problems arise, though, when this is not the case. This happened in KDE in 2017, when a D-Bus service with Polkit authentication was added to KTextEditor. This service is part of a feature which allows an unprivileged user to save a file to a privileged file system location after entering the root password. From the end user’s point of view this makes perfect sense: why shouldn’t the user of a typical single-user desktop system be allowed to change configuration files this way?

Former security team member Sebastian Krahmer was kind of outraged by this idea, though, because the Polkit action lacked a well-defined scope. Writing arbitrary data to arbitrary files on disk can lead to all kinds of problematic situations. Let’s consider a few scenarios:

• a file is saved in a system configuration directory owned by root, like /etc/fstab. This is likely the typical use case considered by the upstream developers.
• a file is (accidentally) saved to an unprivileged location the user controls anyway like /home/$USERNAME/some_file. The privilege escalation would not even be necessary in this case, but acting with root privileges in this location is dangerous.
• a file is saved to a configuration or state directory owned by an unprivileged service user like /var/lib/chrony. Now three different user accounts are involved: the unprivileged user providing the file content and asking for the operation, the root user performing the privileged operation and the service user chrony which actually controls the file system location where the write is about to happen.
• a file on a pseudo file system like /proc or /sys could be changed this way. Pseudo files often have special semantics with regards to the way data is written to them. Without being aware of this, the privileged KTextEditor helper component could cause side effects or simply not fulfill correctly what the user had in mind.
• a target path might not yet exist. Should it be newly created? What ownership and mode should be applied to such a newly created file?
• a target path might exist, but have a special file type. By naively accessing such files, the write could be redirected to unintended locations (by following symbolic links) or denial-of-service could occur (by blocking on a FIFO pipe). What should be done in this case: should the write operation fail, should the special file be silently replaced or should the user be asked interactively what to do?

We can see from this list that many different situations can result from what looked like just a simple “file save” operation in the beginning. We reviewed the code for this KTextEditor feature more closely and discovered CVE-2018-10361, a local root exploit when the privileged back end attempts to save a file in a directory owned by another unprivileged user.

After the finding was fixed by upstream we asked for a number of improvements before we would accept this D-Bus service into openSUSE:

• the destination path should be added to the Polkit authentication message (bsc#1147035). Currently it would only show a generic message about manipulating a privileged file. To prevent potential accidents or even spoofing, the message should clearly state what is being authenticated.
• the target file ownership and mode should be completely defined either by the back end, or by the front end (bsc#1147038). Currently the front end could optionally pass the file owner and group, but not the mode. For creating new files, the GUI part should ideally actively ask the user for the desired file properties. This is because neither the back end nor the front end can reliably guess the mode for new files. Should it be world readable or not? Should it be controlled by root, or by a service account or even another interactive user? This is something that can only be answered by the user asking for the operation to be performed.
• the back end should not replace anything except regular files. Symlinks should not be followed, any other special files should not be accessed or replaced (bsc#1147041).
• when writing to a directory not owned by root, then the back end component should drop privileges to the owner of the directory before performing file operations within it (bsc#1147043).
• a restriction on destination file systems should be implemented, e.g. to prevent the operation on pseudo file systems (bsc#1147045).

We never heard back from upstream or our KDE maintainers on any of these points, therefore this part of KTextEditor is still not enabled on openSUSE. Implementing most of the changes we requested would have been well within reach; only the dynamic authentication message involved some obstacles, because the Qt and KDE framework libraries for Polkit did not fully support this at the time.

KIO Framework for Privileged File System Operations

While there was no progress with the requested improvements of the “save file to an arbitrary location” feature in KTextEditor, developers of the KIO framework around the same time attempted to extend the concept of privileged file operations via D-Bus and Polkit even further. There was an effort to make a full range of privileged file operations available to GUI applications: chmod(), chown(), unlink(), mkdir(), rmdir(), open(), opendir(), rename(), symlink() and utime(). We were asked to participate in design discussions about this feature.

The resulting D-Bus service ended up being something like a mini kernel in user space, offering all kinds of file system APIs. Some of the problems observed in KTextEditor became even worse in this approach. While in KTextEditor it is at least clear that only regular files are supposed to be accessed, nothing is known about the context of the file operations in KIO. All the individual operations are detached from each other. Applications typically need to perform a specific task covering a certain range of file operations that are logically related. One such task might be to atomically replace a file in a privileged location by a new version of the file. This would require a sequence of calls like open() for the new file to be created, a chown() to assign the desired ownership to it and finally a rename() to replace the old file by the new file. The KIO D-Bus service did not have this additional context information and thus could not clearly inform the user about what is going to happen.

Only a single Polkit action “org.kde.kio.file.exec” was used to authenticate any of these privileged file system operations. The authentication message displayed to users is, like in KTextEditor, a generic one. Users won’t be able to determine exactly what kind of file operation they are authenticating. The user will either be presented with multiple authentication requests for a single task (auth_admin Polkit setting) or the D-Bus service will cache authentication for some time (auth_admin_keep Polkit setting) thereby allowing an unknown amount and range of file operations to be performed for an indefinite time span. In both cases the scope of what is authenticated is unclear to an average end user.

Since a generic D-Bus service that offers file operations cannot know what the logical goal of a client application is, the service basically needs to expose all variants of file system operations and the flags influencing them to applications. Modelling this on D-Bus correctly and completely is a difficult task. Such an approach also puts a burden on the applications that now need to implement complex sequences of system calls indirectly via an asynchronous D-Bus IPC interface.

Another approach to make an interface like this work in a robust and safe way could be to implement some form of transaction handling. The application would request a task like “replace /etc/fstab” and register a sequence of calls that are logically related for this task like: open /etc/fstab.new, chmod /etc/fstab.new, rename /etc/fstab.new to /etc/fstab. The back end would then only authenticate and allow these file operations on the requested paths. This again would lead to a highly complex interface, however.

Securely operating in arbitrary file system locations with raised privileges is already a highly difficult task when doing so using plain system calls. The program has to take into account the necessity to perform a privilege drop to the owner of a directory, it needs to avoid following symbolic links in many situations, it might need to open files using the O_PATH flag to avoid accessing dangerous special files unwittingly. The task just seems too complex to cover it generically using an abstract IPC interface. Polkit as an authentication mechanism is also not suited well for such a kind of generic API.

As a consequence of the involved complexities, after long discussions, upstream abandoned this feature. The code is still present in the KIO repository, but the privileged file_helper is not installed.

The kio-admin Back End

With this we arrive at kio-admin. We were asked for inclusion of this D-Bus service in 2022. It is another variation on the “privileged file operation” theme. Only this time it is not an integral feature of the KIO framework, but a separate component running as root that acts as a regular client towards KIO.

We decided not to accept kio-admin for mostly the same reasons as we have stated previously regarding KTextEditor and the KIO framework feature above. In 2024 we have been asked to revisit kio-admin, to check if it improved in the meantime.

Sadly the situation did not change much. The range of file operations offered is very similar to what was proposed for KIO: chown(), chmod(), mkdir(), listing directory contents and so on. In some respects the API is even worse than what was proposed for KIO earlier, because all operations are performed on paths, not on file descriptors. There is less control over individual operations with regards to following symbolic links and other behaviour of system calls. The implementation of the D-Bus service is more complex, requests are asynchronously forwarded by kio-admin to KIO. The kio-admin D-Bus API also uses URIs like “file:///etc/fstab” instead of plain paths.

Again there exists only a single Polkit action “org.kde.kio.admin.commands” which uses a generic authentication message for authorization of any of the offered operations. The scope of the request that gets authenticated remains again unclear to users.

The actual implementation of the file operations found in the KIO framework is often naive with respect to occurrence of symbolic links and also subject to race conditions, should a third user account in the system have control over the directory in which the operations take place.

Integration of kio-admin into the Dolphin File Manager

One of the main use cases of the kio-admin component is found in the Dolphin file manager “admin mode” feature. This is a mode in which all file operations are forwarded to the kio-admin back end, to perform them with raised privileges.

The way this feature is implemented in Dolphin is actually well thought out. There are clear warnings and a visible red bar at the top as long as the “acting as admin” mode is active. Also Dolphin rejects changing symbolic link targets and correctly displays that link permissions cannot be changed.

This cannot completely fix things like race conditions on part of the kio-admin back end, however. When Dolphin sees a regular file for example, and triggers a request at kio-admin to operate on it, the path could be replaced by some other file type by the time the KIO framework starts operating on it.

3) Assessment of Security Concerns

The concerns we have about privileged file operations exposed via D-Bus APIs affect local system security. These days it is often argued that nearly all Linux desktop systems are single-user desktops and thus local system security is not important. The attack surface found in kio-admin can still affect defense-in-depth, though. Consider file operations taking place in directories owned by unprivileged service users or by nobody. If such an account is compromised, then attack vectors like symlink attacks can lead to full privilege escalation. In this sense, every Linux system could be considered a multi-user system, even if no other human interactive users are present.

The general purpose nature of such APIs makes it hard to judge what future uses might look like. Once such an API is accepted into the distribution, it is difficult to keep track of additional consumers of the API. The proliferation of its use, maybe also in the area of non-interactive background tasks, could increase the dangers we already identified.

For these reasons we rejected the inclusion of the kio-admin API into openSUSE up until now.

4) Rationale for Accepting kio-admin into openSUSE

We have dealt with these types of APIs in KDE since 2017 without achieving any notable improvements. As we are responsible for product security we tried to protect our users from potentially harmful components. At this point, though, we don’t believe that this situation will change anytime soon. Meanwhile users still want to use features like the one found in Dolphin, and don’t understand why openSUSE does not include them.

We realize that using non-robust APIs is still an improvement over running graphical applications completely as root. Also in its current form, the likelihood that an operation interactively performed via kio-admin is actually exploited, is low.

There also exists a GNOME desktop component called gvfs which is very similar to kio-admin. It was accepted into openSUSE in 2017 without looking in detail at its purpose and API design. In the context of the discussions about KTextEditor we performed a second more in-depth review, during which we found problems closely resembling the concerns about kio-admin discussed in this article. Still, we decided to keep it in openSUSE, due to historical reasons.

Thus, on the grounds of equal treatment and to allow for a good user experience on openSUSE, we have now decided to set aside our concerns about kio-admin and admit it into openSUSE. This feels like the pragmatic choice to us given the circumstances. We would have liked to see a more robust and transparent API design, however. We hope that upstream developers find ways to better address our concerns in the future, meanwhile we still recommend end users to be careful when using these features and take heed of the recommendations we give in the next section.

5) Recommendations for Users of kio-admin or gvfs

Unfortunately there are many pitfalls when performing privileged file operations. We assume that even power users tend to make mistakes when running shell commands as root operating in directories controlled or influenced by non-root users, like in /tmp. Following is some general advice that can help to avoid such mistakes.

For a start, APIs like kio-admin and gvfs are usually safe to use when file operations happen in directories owned by root, like in /etc (note that sub-directories of /etc can again be owned by non-root users). Special care should be taken when changing files in directories controlled by another user, like another user’s home directory or files owned by a service user account.

In such scenarios it is safer to perform the operations in a root shell, and one should be very careful not to follow symbolic links while doing so. Many file management utilities offer specific switches to avoid following them. The chmod utility, for example, will by default follow symbolic links in the target file path unless the -h switch is passed to it.

Even these switches only protect against symbolic links in the final component of a path. Consider the command chmod -h 644 /var/lib/chrony/sub-dir/target. /var/lib/chrony is controlled by the chrony service user account. Thus the unprivileged chrony user can turn sub-dir into a symbolic link pointing to a privileged location like /etc. If /etc/target existed then the command above would make this file world-readable.

Therefore an even better approach to editing files owned by another account is to assume their identity, for example by invoking sudo -u <user> -g <group> /bin/bash. This way no elevated privileges that could be abused by a compromised account are present in the first place.

6) Next Steps for Inclusion of kio-admin

Documenting our concerns in this blog post is the first step of the process to add kio-admin to openSUSE. We will reference this blog post and some hints in dedicated README files added to the kio-admin and gvfs packages. We will also document this in the openSUSE wiki. When all of this is done we will perform the necessary steps to allow kio-admin into openSUSE Tumbleweed, which we believe will happen within the next two weeks.

7) References

• kio-admin Git Repository
• Dolphin file manager Git repository
• KTextEditor Git repository
• GNOME gvfs wiki page

La noticia no es nueva, pero hasta hoy no me había percatado de que la aplicación crow-translate ahora forma parte del ecosistema de la comunidad KDE

Desde que conocí la aplicación crow translate para traducir texto en mi sistema, ha sido una aplicación imprescindible para mí y ya en 2020 escribí sobre ella en el blog:

• https://victorhckinthefreeworld.com/2020/04/27/crow-translate-aplicacion-simple-ligera-y-de-software-libre-para-traducir-texto/

Antes su desarrollo se realizaba en su repositorio en Github, y hoy me encuentro que desde el pasado julio de 2024 la aplicación ha pasado a formar parte de la comunidad KDE.

¿Qué implica eso? Que el desarrollo ahora se realiza en un repositorio git de un servidor propio de KDE, que tendrá reportes utilizando el sistema de reporte de errores de KDe, que tendrá detrás toda la comunidad de KDE para mantener el programa, que será traducido a multitud de idiomas y que se integrará mejor con el escritorio Plasma de KDE.

Como usuario de Crow translate y como usuario de Plasma, el escritorio de KDE, yo creo que todos estos cambios son ventajas.

La aplicación se abre al incio del sistema y el uso más común que le doy es seleccionar un texto de una página web, o de un documento, etc y pulsar la combinación de teclas Ctrl+Alt+E lo que me abre la ventana con la traducción que puedo consultar, copiar, escuchar.

Además para quienes usan mucho la línea de comandos, crow translate también se puede manejar desde la línea de comandos y nos ofrecerá traducciones en la terminal lo que también puede ser interesante.

Aplaudir la decisión tanto de crow translate como de KDE de colaborar juntos con esta aplicación que se convierte en una imprescindible en mi sistema GNU/Linux con Plasma. Si no la has probado te animo a que lo hagas y compruebes su utilidad.

Ha pasado una semana desde el lanzamiento de Plasma 6.3 y es hora de empezar a mostrar qué ofrece para seguir siendo considerado el escritorio más vanguardista. En esta ocasión sigo la serie con las novedades gráficas de Plasma 6.3 ya que la mejora de la calidad de las pantallas no puede ser ignorada por los desarrolladores.

Novedades gráficas de Plasma 6.3

El pasado 4 de febrero fue lanzado Plasma 6.3, una actualización mayor del entorno de trabajo más moderno, funcional y llenos de posibilidades que te puedes instalar en tu PC, y a un precio ridículo: 0 €. Solo requiere que inviertas tiempo para aprender a hacerlo.

Esta versión consolida su gran paso de tecnologías QT5/KF5 a QT6/KF6 en tiempo récord, abriendo un abanico de posibilidades nunca antes vistas, como se puede ver en las novedades gráficas: mejoras en las ampliaciones, en las variaciones de tono de la pantalla o en los plasmoides.

En palabras de sus desarrolladores:

La novedad más importante relacionada con los gráficos es una enorme revisión del funcionamiento del escalado fraccionario. En Plasma 6.3, KWin realiza un gran esfuerzo para ajustar los elementos a la cuadrícula de píxeles de la pantalla, lo que reduce en gran medida la borrosidad y las fisuras visuales y produce imágenes más nítidas y definidas.

Esto también funciona en niveles muy altos de ampliación, ya que el efecto de ampliación de KWin cambia a una representación nítida y perfecta de píxeles y superpone una cuadrícula sobre la pantalla. De hecho, se puede mostrar cómo se ven los píxeles individuales en relación con otros. Muy útil para artistas y diseñadores.

En lo que se refiere al color, los colores de la pantalla son más precisos cuando se usa la función de Luz nocturna, independientemente del uso de perfiles ICC, y KWin ofrece la opción de escoger la precisión del color de la pantalla (aunque a veces puede afectar al rendimiento del sistema).

Un detalle menor aunque interesante es que los widgets situados en el escritorio son ligeramente traslúcidos, al igual que las ventanas emergentes de los widgets que residen en el panel:

Más información: KDE

Las novedades generales de Plasma 6.3

Aprovecho para realizar un listado de las novedades generales de Plasma 6.3 novedades extraídas de 9to5linux.

• Posibilidad de clonar un panel.
• Posibilidad de establecer atajos de teclado para mover ventanas entre zonas de mosaicos de Custom Tiling en función de la direccionalidad.
• Soporte para recordar el escritorio virtual activo por actividad.
• Página renovada de la tableta gráfica en la configuración del sistema.
• Opción de preferir la precisión del color de la pantalla en KWin.
• Notificaciones de batería baja para auriculares inalámbricos que expongan adecuadamente la información de la batería.
• Nueva configuración el touchpad para que se desactive automáticamente al conectar un ratón.
• Mejor escalado fraccional para todos.
• Los widgets colocados en el escritorio sean ligeramente translúcidos.
• Asignación una contraseña aleatoria por defecto al punto de acceso a la red.
• Nuevo servicio para detectar y avisar a los usuarios con una notificación explicando lo que ocurre cuando el sistema se queda sin memoria y el kernel termina una aplicación.
• Plasma Discover ha sido actualizado para mostrar a los usuarios cuando las aplicaciones han sido empaquetadas directamente por su desarrollador o verificadas por un tercero de confianza.
• Mayor precisión el progreso de la instalación.

• Posibilidad de desactivar temporalmente las reglas de ventana de KWin en lugar de eliminarlas.
• Indicador de agrupación en el widget Administrador de tareas ahora sigue el color de acento actual.
• Los iconos simbólicos apropiados ahora serán sustituidos automáticamente por iconos de aplicaciones en el área de la bandeja del sistema.
• La aplicación Centro de información ahora mostrará todas tus GPUs y el recuento de ciclos de la batería de tu portátil.
• Posibilidad de intercambiar las funciones de los botones del lápiz de la tableta de dibujo.
• Se podrá mostrar la cola de impresión de cada impresora en línea y un spinner ocupado para cualquier impresora que esté imprimiendo en ese momento en el widget Impresoras.
• Se notificará a los usuarios en la pantalla de cierre de sesión cuando reinicien su sistema en el menú del gestor de arranque.
• Eliminado la categoría de menú «Configuración» del lanzador de aplicaciones Kickoff y todo su contenido se ha trasladado a la categoría «Sistema».

Más información: KDE

La entrada Novedades gráficas de Plasma 6.3 se publicó primero en KDE Blog.

Data breaches and cyber threats are becoming increasingly common and securing your personal and professional information has never been more critical.

Users transitioning from Windows to Linux through the Upgrade to Freedom campaign can use openSUSE’s tools to protect sensitive data, which include full disk encryption (FDE).

Full disk encryption during installation ensures maximum security. It safeguards all data on your hard drive by encrypting it and makes it unreadable without an decryption key. This level of protection is vital for preventing unauthorized access if your laptop or desktop is lost or stolen.

FDE with openSUSE is both user-friendly and powerful. The setup with advanced security features is easy.

For users seeking feature parity with Windows BitLocker, openSUSE offers Full Disk Encryption (FDE) secured by a TPM2 chip or a FIDO2 key. This advanced setup enhances security by storing encryption keys within the TPM, which ensures that only a trusted system configuration can unlock the disk. For a step-by-step guide on enabling this feature, read the Quickstart in Full Disk Encryption with TPM and YaST2 article.

Here’s a step-by-step guide to set up FDE on your system:

Step 1: Download and Boot openSUSE

• Visit get.opensuse.org to download the latest version of openSUSE Leap or Tumbleweed.
• Create a bootable USB drive using tools like balenaEtcher or another image writer.
• Restart your computer and boot from the USB drive to begin the installation process.

Step 2: Configure Encryption During Installation

• Once the installer starts, select your preferred language and keyboard layout.
• In the partitioning setup, choose Guided Setup with Encrypted LVM.
• Set a strong passphrase for encryption. This passphrase will be required every time the system boots. Use a mix of upper and lower case letters, numbers and special characters for optimal security.
• Proceed with the installation as directed by the installer.

Step 3: Verify Encryption Settings

After installation is complete and the system restarts, you’ll be prompted to enter your encryption passphrase. Once entered, openSUSE tools will decrypt the disk and boot normally. To confirm encryption is active:

• Open a terminal or console.
• Run the command lsblk -f to verify that your disk is listed with the encryption type (e.g., crypto_LUKS).

The output might look something similar to the following:

NAME        FSTYPE      FSVER LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                     
├─sda1      ext4        1.0     4a83v1e1-e8d2-4e38-815d-fd79j194f5   25G    30%    /
└─sda2      swap        1           d2e18c23-9w4b-4d26-p1s2-cm2sd64tx9de                
sdb                                                                                     
└─sdb1      crypto_LUKS 1           10bb2vca-81r4-418b-a2c4-e0f6585f2c7a                
  └─luks    ext4        1.0         8a9wka1b-7e9c-1a1f-a9f7-3c82x1e4e87f   150G    10%    /mnt/data

Step 4: Regular Backups

While FDE protects your data, it does not prevent data loss from hardware failure or accidental deletion. Regularly back up your data to an encrypted external drive or a secure cloud service to ensure its safety.

Post-Installation Encryption If you want to encrypt an existing partition after installation, visit the openSUSE wiki page about encryption.

Enhanced Security for Modern Challenges

Setting up full disk encryption on openSUSE not only protects your data but also aligns with the Upgrade to Freedom campaign’s mission of empowering users to maintain control over their hardware and privacy. By combining open-source software with good security practices, openSUSE ensures that users can confidently embrace a more secure digital future.

For additional guidance and community support, visit the openSUSE forums or join discussions at your local Linux user group.

Please be aware that some hardware configurations may require additional drivers or BIOS settings adjustments for full disk encryption to fully function properly. Check your device’s compatibility and update your firmware before proceeding.

A OWASP São Paulo é um dos capítulos brasileiros entre os mais de 270 capítulos ativos ao redor do mundo. Nosso propósito é promover a missão da OWASP, tornando a segurança de aplicações mais acessível e compreensível, para que indivíduos e organizações possam tomar decisões informadas sobre os reais riscos envolvidos.

Em 2025, contamos com um novo Chapter Leader, Carlos Augusto Souza Carvalho, e juntos realizaremos encontros para fomentar o compartilhamento de conhecimento, a troca de experiências e o aprendizado contínuo sobre segurança de software.

Abaixo a estrutura atual da OWASP SP:

Alessandro (Cabelo) de Oliveira Faria : Leader
Cofundador da empresa MultiCortex, OITI TECHNOLOGIES e da iniciativa Global openSUSE Linux INNOVATOR, membro fundador do Instituto Fóton+ de Tecnologias Quânticas, Autodidata, Pesquisador, entusiasta por inovação desde 1983 (aos 11 anos). Leva Linux a sério desde 1998 junto com pesquisas e trabalhos em biometria e visão computacional. Experiência com biometria facial desde 2003, redes neurais artificiais e neurotecnologia desde 2009. Inventor da tecnologia CERTIFACE, Linux HPC EXO AI, mais de 200 palestras ministradas, 14 artigos impressos publicados, mais de 9 milhões de acessos nos 120 artigos publicados no portal Viva O Linux, Mentor Cybersecuritygirls BR , Docente na FIA, Membro Oficial e Embaixador OpenSUSE Linux Latin America, Chapter Leader OWASP SP, Colunista Técnico, Engenheiro openSUSE Linux AWS, Global Innovator Intel, Membro Notável I2AI, Membro do Conselho Consultivo da ABRIA, Embaixador de Inovação Credicitrus, Innovation Advisor do Peck Advogados e Global Intel Innovator Champion 2024 e 2025.

Carlos Augusto Souza Carvalho : Leader
Sólida experiência em Infraestrutura de TI, com ênfase em redes corporativas (on premisses, híbridas e cloud AWS, GCP, Azure e Oracle Cloud), administração de sistemas operacionais linux e windows e Segurança da Informação, atuando em empresas de médio e grande porte e com destaque no mercado há dezoito anos. Boa capacidade de interlocução (professor de informática por seis anos) e planejamento (coordenador por dois anos de treinamento profissional e gestão de implantação de ti).

Ricardo Martins: Board Members
rofissional de segurança cibernética com expertise em implementação de políticas de segurança da informação baseadas nas normas ISO 27001 e ISO 27701, e análise forense de malware. Líder de equipe na ResolveSec, orquestrando soluções de segurança para proteger dados, sistemas e reputações contra ameaças cibernéticas. Certificada em aplicativos web, com conquistas em competições de segurança como CTF (RoadSec) e HackaFlag. Apaixonada por novas tecnologias, também atua como palestrante, publicadora e mentora, compartilhando conhecimentos e insights sobre segurança cibernética

Ines Brosso : Board Members
Profissional experiente em Tecnologia de Segurança da Informação nas áreas Financeira e Industrial com histórico comprovado de trabalho em academia de ensino superior realizando pesquisas, eventos e publicações. Profissional de educação sólida, qualificada em Projetos de Análise de Segurança, Segurança em Nuvem, Big Data, Biometria, Ciência da Computação, Inteligência Artificial, Aprendizado de Máquina, Segurança de Rede, Segurança de Computador Quântico e Membro da OWASP São Paulo.

Christiano Linuxmen: Board Members
Com mais de duas décadas de experiência, sou um Consultor na Ápice Solutions, especializado em DevOps, automação de infraestrutura e segurança da informação. Neste papel, eu aplico minhas habilidades em ferramentas como Ansible, Docker e Zabbix para otimizar operações de cloud e garantir a integridade dos sistemas. A minha missão é fortalecer os ambientes de TI através de práticas ágeis e seguras, contribuindo para o crescimento sustentável da organização. Fundador do Papo de Sysadmin e Líder do AWS User Group Interior de São Paulo, eu me orgulho em promover uma comunidade mais segura e informada, utilizando minha expertise para impactar positivamente nesses ecossistemas.

Eduardo Neves: Board Members
Ajudo especialistas em DevOps e SRE a se tornarem mestres da observabilidade. Nossa comunidade é mais do que excelente, é uma família comprometida em compartilhar conhecimento e apoiar uns aos outros. O conteúdo aqui é cuidadosamente desenvolvido, com cases reais e estudos que apoiarão sua carreira. Além disso, a didática é objetiva, garantindo uma experiência de aprendizado envolvente e eficiente.
Membro ativo nas comunidades opensource desde 1997, trabalhou em diversos setores da economia, como financeiras, seguradoras, e-commerces, portais de internet. Também ja atuou nas mais diversas esferas do Governo, tanto Federal, Estadual e Municipal. Palestrante em mais de 80 eventos nacionais e internacionais. Atualmente atua nas comunidades Papo de SysAdmin e elastic campinas.

Ha pasado una semana desde el lanzamiento de Plasma 6.3 y es hora de empezar a mostrar qué ofrece para seguir siendo considerado el escritorio más vanguardista. En esta ocasión inicio la serie con las novedades para artistas en Plasma 6.3 ya que estos creadores están siendo muy mimados por los desarrolladores.

Novedades para artistas en Plasma 6.3

El pasado 4 de febrero fue lanzado Plasma 6.3, una actualización mayor del entorno de trabajo más moderno, funcional y llenos de posibilidades que te puedes instalar en tu PC, y a un precio ridículo: 0 €. Solo requiere que inviertas tiempo para aprender a hacerlo.

Esta versión consolida su gran paso de tecnologías QT5/KF5 a QT6/KF6 en tiempo récord, abriendo un abanico de posibilidades nunca antes vistas, siendo unos de los grandes beneficiados de este nuevo lanzamiento los artistas digitales, quizás por el alza en calidad y prestigio de una de las Kill App de la Comunidad KDE: Krita.

En palabras de sus desarrolladores:

Queremos hacer de Plasma la mejor plataforma para la creatividad, y Plasma 6.3 da un paso más en esa dirección al proporcionar funciones que ayudan a los artistas a optimizar y personalizar sus tabletas gráficas.

La página Tableta de dibujo de las preferencias del sistema se ha revisado y dividido en varias pestañas para mejorar la organización de su contenido, donde se han añadido nuevas opciones de configuración en cada sección:

• Se puede asignar un área de la superficie de la tableta de dibujo a toda el área de la pantalla.
• Hemos perfeccionado la función de calibración de la tableta para que produzca calibraciones más precisas.
• La función de prueba del lápiz muestra información sobre la inclinación y la presión.
• Se puede personalizar la curva de presión y el intervalo del lápiz para cortar las partes altas y/o bajas.
• También se pueden reasignar o intercambiar las funciones de los botones del lápiz.

Más información: KDE

Las novedades generales de Plasma 6.3

Aprovecho para realizar un listado de las novedades generales de Plasma 6.3 novedades extraídas de 9to5linux.

• Posibilidad de clonar un panel.
• Posibilidad de establecer atajos de teclado para mover ventanas entre zonas de mosaicos de Custom Tiling en función de la direccionalidad.
• Soporte para recordar el escritorio virtual activo por actividad.
• Página renovada de la tableta gráfica en la configuración del sistema.
• Opción de preferir la precisión del color de la pantalla en KWin.
• Notificaciones de batería baja para auriculares inalámbricos que expongan adecuadamente la información de la batería.
• Nueva configuración el touchpad para que se desactive automáticamente al conectar un ratón.
• Mejor escalado fraccional para todos.
• Los widgets colocados en el escritorio sean ligeramente translúcidos.
• Asignación una contraseña aleatoria por defecto al punto de acceso a la red.
• Nuevo servicio para detectar y avisar a los usuarios con una notificación explicando lo que ocurre cuando el sistema se queda sin memoria y el kernel termina una aplicación.
• Plasma Discover ha sido actualizado para mostrar a los usuarios cuando las aplicaciones han sido empaquetadas directamente por su desarrollador o verificadas por un tercero de confianza.
• Mayor precisión el progreso de la instalación.

• Posibilidad de desactivar temporalmente las reglas de ventana de KWin en lugar de eliminarlas.
• Indicador de agrupación en el widget Administrador de tareas ahora sigue el color de acento actual.
• Los iconos simbólicos apropiados ahora serán sustituidos automáticamente por iconos de aplicaciones en el área de la bandeja del sistema.
• La aplicación Centro de información ahora mostrará todas tus GPUs y el recuento de ciclos de la batería de tu portátil.
• Posibilidad de intercambiar las funciones de los botones del lápiz de la tableta de dibujo.
• Se podrá mostrar la cola de impresión de cada impresora en línea y un spinner ocupado para cualquier impresora que esté imprimiendo en ese momento en el widget Impresoras.
• Se notificará a los usuarios en la pantalla de cierre de sesión cuando reinicien su sistema en el menú del gestor de arranque.
• Eliminado la categoría de menú «Configuración» del lanzador de aplicaciones Kickoff y todo su contenido se ha trasladado a la categoría «Sistema».

Más información: KDE

La entrada Novedades para artistas en Plasma 6.3 se publicó primero en KDE Blog.

La cuestión se ha planteado en la lista de correos sobre si openSUSE Leap debería abandonar la compatibilidad con Bios Legacy

Hace unos días en la lista de correo de factory de la comunidad de openSUSE se realizó una propuesta debatir sobre eliminar el soporte de arranque Boot Legacy para las próximas versiones de SUSE Linux Enterprise Server 16 (SLES) y openSUSE Leap 16. openSUSE Tumbleweed no se vería afectado por este cambio.

El mensaje inicial de la lista de correo, por parte del responsable de publicaciones de Leap decía:

SUSE está evaluando la eliminación de la compatibilidad con el boot legacy, por favor, háganos saber si Usted prevé cualquier problema. Tenga en cuenta que la compatibilidad con SLES 16 / Leap 16 requiere x86_64-v2, por lo que personalmente creo que no habrá muchos casos en los que un sistema de este tipo no sería compatible con UEFI.

Estaba un poco preocupado por los escenarios virtualizados, deberíamos asegurarnos de que uefi es el valor predeterminado para las nuevas máquinas virtuales, ya que ahora parece ser un boot legacy.

Si tiene alguna inquietud, compártala en code-o-o https://code.opensuse.org/leap/features/issue/194

Me aseguraré de que la gerencia de productos lo vea. Todos los comentarios son bienvenidos.

Se abría un debate en el que los usuarios de openSUSE pueden exponer sus casos particulares sobre la idoneidad o no de abandonar el arranque de Bios Legacy, lo que dejaría atrás muchas máquinas que disponen de este tipo de arranque frente al UEFI actual.

El problema no es únicamente para los equipos personales, si no para servidores u otros equipos profesionales que aún se mantienen con Bios Legacy, si llegado el caso se quisiera instalar openSUSE o SUSE en esos equipos.

Todavía el hilo está en discusión expresando cada quien su punto de vista, pero hay quien ha llegado a sugerir que podría poner en marcha y mantener una distribución no oficial de openSUSE para arquitecturas antiguas/exóticas.

Veremos en qué queda esta propuesta, si es aceptada o se echa atrás por petición popular.

Me alegra compartir con todos vosotros la primera actualización de Plasma 6.3, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Primera actualización de Plasma 6.3

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

La Comunidad KDE ha publicado la primera actualización de Plasma 6.3, una versión que viene a subsanar los errores más graves de esta nueva versión del escritorio

Así que me congratula en presentar que hoy martes 18 de febrero de 2025, una semana después de liberar el código de Plasma 6.3 la Comunidad KDE presenta la primera actualización de errores.

• Breeze: Corrección de fallos en algunas aplicaciones que no son de KDE.
• Kinfo.Corrección del parpadeo del tamaño de página.
• KScreen Doctor: arreglar salida modo dpms.

Más información: KDE

Las novedades generales de Plasma 6.3

Aprovecho para realizar un listado de las novedades generales de Plasma 6.3 novedades extraídas de 9to5linux.

• Posibilidad de clonar un panel.
• Posibilidad de establecer atajos de teclado para mover ventanas entre zonas de mosaicos de Custom Tiling en función de la direccionalidad.
• Soporte para recordar el escritorio virtual activo por actividad.
• Página renovada de la tableta gráfica en la configuración del sistema.
• Opción de preferir la precisión del color de la pantalla en KWin.
• Notificaciones de batería baja para auriculares inalámbricos que expongan adecuadamente la información de la batería.
• Nueva configuración el touchpad para que se desactive automáticamente al conectar un ratón.
• Mejor escalado fraccional para todos.
• Los widgets colocados en el escritorio sean ligeramente translúcidos.
• Asignación una contraseña aleatoria por defecto al punto de acceso a la red.
• Nuevo servicio para detectar y avisar a los usuarios con una notificación explicando lo que ocurre cuando el sistema se queda sin memoria y el kernel termina una aplicación.
• Plasma Discover ha sido actualizado para mostrar a los usuarios cuando las aplicaciones han sido empaquetadas directamente por su desarrollador o verificadas por un tercero de confianza.
• Mayor precisión el progreso de la instalación.

• Posibilidad de desactivar temporalmente las reglas de ventana de KWin en lugar de eliminarlas.
• Indicador de agrupación en el widget Administrador de tareas ahora sigue el color de acento actual.
• Los iconos simbólicos apropiados ahora serán sustituidos automáticamente por iconos de aplicaciones en el área de la bandeja del sistema.
• La aplicación Centro de información ahora mostrará todas tus GPUs y el recuento de ciclos de la batería de tu portátil.
• Posibilidad de intercambiar las funciones de los botones del lápiz de la tableta de dibujo.
• Se podrá mostrar la cola de impresión de cada impresora en línea y un spinner ocupado para cualquier impresora que esté imprimiendo en ese momento en el widget Impresoras.
• Se notificará a los usuarios en la pantalla de cierre de sesión cuando reinicien su sistema en el menú del gestor de arranque.
• Eliminado la categoría de menú «Configuración» del lanzador de aplicaciones Kickoff y todo su contenido se ha trasladado a la categoría «Sistema».

Más información: KDE

La entrada Primera actualización de Plasma 6.3 se publicó primero en KDE Blog.

Las nuevas instalaciones de openSUSE Tumbleweed utilizarán el módulo de seguridad SELinux de manera predeterminada en vez de AppArmor

Las nuevas instalaciones que se realicen de openSUSE Tumbleweed ya tendrán configurado de manera predeterminada SELinux como módulo de seguridad del kernel Linux reemplazando a AppArmor que se venía utilizando hasta ahora.

Tal como hace unos días se anunció en la lista de correo, este cambio se ha hecho efectivo a partir de la snapshot 20250211. A partir de esa ISO las personas que instalen openSUSE Tumbleweed a través de la imagen ISO verán SELinux como opción predeterminada en el instalador. Pero si esa persona prefiere utilizar AppArmor en lugar de SELinux, puede cambiar la selección a AppArmor manualmente en el instalador.

SELinux se habilitará de forma predeterminada solo para nuevas instalaciones. Las instalaciones existentes no se verán afectadas por el cambio. Aunque hay un tutorial en la wiki de openSUSE para realizar el cambio en sistemas ya instalados si se desea.

También se confirmó que la serie estable de sistemas operativos openSUSE Leap 15.x no se ve afectada por este cambio y permanecerá con AppArmor.

El cambio para instalar SELinux de forma predeterminada se está implementando y se alinea con la decisión de aumentar la adopción de SELinux tanto para SUSE como para openSUSE. Se espera que aumente la seguridad al limitar más servicios de forma predeterminada. SELinux es conocido por sus múltiples características de seguridad y su uso generalizado en entornos empresariales.

Además SELinux tiene una comunidad más grande, es mejor aceptado para entornos de alta seguridad y tiene una historia de desarrollo mucho mejor.

Enlaces de interés

• https://news.opensuse.org/2025/02/13/tw-plans-to-adopt-selinux-as-default/
• https://en.opensuse.org/Portal:SELinux/Setup#Setup_SELinux_on_existing_Tumbleweed_systems
• https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G3W5NIY3OKRBHPHWTPYEUPSS4LKZN77N/
• https://es.wikipedia.org/wiki/SELinux