This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The below featured highlights listed on the community’s blog feed aggregator from July 21 to 27. Some of the most recent blogs openSUSE Conference 2025, updates on Tumbleweed developments, and important security insights.

Here is a summary and links for each post:

openSUSE Conference 2025 Highlights

openSUSE Conference 2025 - Ish Sookun shared his experience attending oSC25 in Nuremberg, Germany, including his perspective as a newly elected openSUSE Board member. The conference brought together developers, contributors, and open-source enthusiasts from around the world. Key highlights included setting up an on-site openSUSE Shop to make swag more accessible to international attendees, keynotes from SUSE leadership emphasizing the power of open collaboration, and technical presentations covering topics like SELinux security improvements and distributed Kubernetes clusters. Ish also presented talks on improving openSUSE membership management and building mirrors in Mauritius.

Tumbleweed Updates

openSUSE Tumbleweed revision de la semana 30 de 2025 - Victorhck provided a detailed review of Tumbleweed snapshots 0718, 0722, and 0723 in Spanish and noted a delay due to SELinux 3.9 debugging. Key updates included KDE Plasma 6.4.3, Mesa 25.1.6, Apache 2.4.64, and Linux kernel 6.15.7. Snapshot 0724 is in quality control and expected to bring SELinux 3.9, Bash 5.3, and Firefox 141.0.

Tumbleweed – Review of the weeks 2025/30 - Dominique Leuenberger provided a detailed review of Tumbleweed snapshots like that listed above.

Security Insights

SUSE Security Team Spotlight Spring 2025 - The SUSE security team shared insights from their spring 2025 work, including reviews of new Polkit features in GDM, Flatpak, and ModemManager. They also detailed privilege escalation vulnerabilities found in cyrus-imapd and configuration changes for systemd-coredump.

Community and Advocacy

Urgency to Switch from Windows 10 Builds - Douglas DeMaio highlighted the openSUSE Project’s participation in the End of 10 campaign, urging users to migrate from Windows 10 (which ends support in October) to Linux-based operating systems. The article emphasizes both cybersecurity risks of staying on unsupported systems and the environmental benefits of extending older hardware life through Linux adoption.

Technical Deep Dives

Dealing with multiple syslog protocols in syslog-ng made easy - Peter Czanik explained the new transport(auto) option in syslog-ng that simplifies handling multiple syslog protocol variants (RFC3164, RFC5424) through a single source driver, making syslog configuration more straightforward.

KDE Community

Esquinas inferiores redondeadas – Esta semana en Plasma - Baltolkien translated Nate Graham’s weekly Plasma update in Spanish covering Plasma 6.5 developments, including the implementation of automatically rounded bottom window corners and various UI improvements.

Control del nivel de tinta de la impresora – Esta semana en Plasma - Another Spanish translation by Baltolkien of Nate Graham’s weekly Plasma update, featuring printer ink level notifications, notification handling improvements, and various bug fixes in Plasma 6.4.4 and 6.5.

Community Events

Akademy 2026 busca sede ¡anímate y presenta una candidatura! - Baltolkien announced that KDE’s annual developer conference Akademy 2026 is seeking a European host venue for its 30th anniversary celebration, providing details on requirements and how to submit a proposal.

View more blogs or learn to publish your own on planet.opensuse.org.

The openSUSE Conference 2025, was held from 26 - 28 June at the vibrant Z-Bau, House of Contemporary Culture, Nuremberg, Germany. I had the pleasure of attending with my colleagues Eddy Lareine and Alex Bissessur. It marked my third time attending and speaking at the openSUSE Conference in Germany, and my fifth international openSUSE talk, after the Africa Internet Summit 2019 in Kampala, Uganda and the openSUSE Asia Summit 2019 in Bali, Indonesia.

My First Conference as a Board Member

Earlier this year, I was elected to the openSUSE Board, making this year's conference a little different, with added responsibilities.

Two days before the conference began, the Board held our face-to-face meetings. We voted on a few pending items and prepared for the Board's public session with the community, which was scheduled for Friday, 27 June at 6 p.m. These pre-conference meetings were insightful, especially for me as a new Board Member. I learned a great deal from more seasoned members like Simon Lees, Shawn Dunn, and our Chair Gerlald Pfeifer. I also benefitted from the perspectives of former Board Members Douglas DeMaio and Patrick Fitzgerald, who also joined the sessions. Although Jeff Mahoney and I started our mandates at the same time, his experience and understanding of how SUSE and openSUSE intersect brought invaluable context to many of the discussions.

Swag at the conference

One of my proposals as a Board Member was to set up an openSUSE Shop at the conference venue. This initiative allowed attendees, especially those visiting from outside Europe, to purchase openSUSE swag such as t-shirts, caps, tote bags, and mugs. For many of us from regions like Africa or islands like Mauritius, international shipping fees often exceed the actual item costs. This shop helped address that.

Thankfully, Eddy and Alex volunteered to help run the shop, so we didn't need to recruit more volunteers. However, managing the swag table while attending sessions was no easy feat. We had to take turns so we could still attend the talks we were interested in and present our own sessions (Alex and I each had two talks spread across different days).

Day 1 — Keynotes, Community Energy and Technical Deep Dives

The conference opened with a keynote address by SUSE CEO Dirk-Peter van Leeuwen. He spoke from the heart, about his roots as an engineer, his passion for coding, and his belief in the power of community. He reminded us of how openSUSE reached its 20-year milestone, highlighting major contributions like YaST, KDE integration, and the Open Build Service (OBS), the latter being adopted by the Cloud Native Computing Foundation for running Kubernetes builds.

Proprietary software development does not get you anywhere, it has to be open.
— Dirk-Peter van Leeuwen

That statement received a resounding applause.

Next up was Rick Spencer, SUSE General Manager, who emphasized that openSUSE is not just a collection of distros, but a single project with a unified purpose. He encouraged contributors to see beyond labels like Tumbleweed or Leap, and instead, embrace a collaborative spirit. His closing call-to-action was simple but powerful:

Join the momentum, every contribution matters.
— Rick Spencer

Later that day, I also attended Cathy Hu's talk on "SELinux — current state in (open)SUSE" while keeping an eye on the shop. As the maintainer of openSUSE's SELinux policy and userspace toolchain, Cathy gave a thorough overview of security improvements in the distro.

The second keynote was delivered by Peer Heinlein, CEO of the Heinlein Group. He talked about the risks of relying on proprietary software, referencing the fate of ownCloud after its acquisition by Kiteworks. In response, the Heinlein Group forked the open-source ownCloud Infinite Scale (OCIS) codebase to launch OpenCloud.

Midway through his talk, I had a déjà vu moment as his name sounded familiar. That's when I remembered that Peer Heinlein is the author of the book Dovecot: POP3/IMAP Servers for Enterprises and ISPs, a crucial reference when I built the email infrastructure for La Sentinelle five years ago.

After his talk, I introduced myself, shared how his book helped me, and thanked him in person. I took a selfie with him and Richard brown, the former openSUSE Board Chair who has always pushed me to be more involved in the project.

I attended the session on Leap 16.0 Beta, by Luboš Kocman, during which he unveiled the new Leap wallpaper.

We were very happy to see the green lizard on the wallpaper, a photo taken by our dear friend and fellow Mauritian, Arwin Neil Baichoo and submitted for the Leap 16.0 and Tumbleweed wallpaper collection. He made us proud. 😊

Day 2 — Talks on Community, Infrastructure, and the African Context

I delivered my first talk in the "Gallerie" room titled "2 cents on improving openSUSE Membership (Management)".

I presented my thoughts on how we could improve the membership process through a custom Laravel-based platform. I had a productive follow-up discussion afterward.

Later, Alex gave his talk on "Geographically Distributed Kubernetes Clusters", highlighting the challenges cloud enthusiasts face in Mauritius, where GCP, AWS, and Azure are absent.

He described how unreliable power and lack of local cloud services inspired him and his friends to build a distributed Kubernetes cluster to host their own blogs and applications.

My second talk, "Building openSUSE Mirror(s) in Mauritius", took place at 4 p.m. in the main hall. It was a status update on the mirror infrastructure project I began in 2022.

I shared lessons learned, improvements to sync strategies, and announced that Kaldera is sponsoring a second mirror in Mauritius, soon to be the fourth mirror in Africa.

The day concluded with the openSUSE Board Q&A session at 6 p.m. Gerald opened with a summary of proposed updates to election and membership rules, and I expanded on our membership platform. Jeff, Simon, and Shawn addressed governance structure proposals. The session felt productive, open, and reflective of the community's spirit.

Day 3 — Bring openSUSE swag for folks back home

On the final day, Alex gave his second talk, "Production-Ready Virtualisation with Harvester and Longhorn." He addressed how recent changes in pricing/licensing by a major virtualization vendor created uncertainty, especially in Africa. Thus, prompting many to seek alternatives.

Harvester and Longhorn, being open-source, hyperconverged solutions, offer a practical alternative at a time when cloud-native infrastructure is becoming the default.

At the end of day, as we were wrapping up, Doug said that we had a few conference t-shirts left and if I would like to bring back home some of them. Naturally, I agreed as I know friends back home would love that.

In fact, I distributed the t-shirts during my talk about the openSUSE Project at the Developers Conference 2025 (Mauritius), which happened just a few weeks after the openSUSE Conference.

Wrapping Up

This year's conference was memorable for many reasons, my new role on the Board, the warm community spirit, the brilliant talks, and of course, the friendships and collaborations that deepened along the way. Videos from all the sessions at oSC25 are available on YouTube.

A big thanks to everyone who made the openSUSE Conference 2025 a success.

Looking forward to seeing you all again in 2026!

Dear Tumbleweed users and hackers,

First off, it has been a bit too quiet from my side on the weekly reviews. The last one published was 2025/25 – the ‘error’ for you missing out on the information is solely on my side: first, there was the openSUSE conference, which was a lot of fun seeing many of you (hopefully many more next year). After that, I dared to take a vacation, which probably nobody realized, as Tumbleweed kept rolling just fine without me. I’ll spare you all the changes that happened in the weeks when no review was conducted. Only so much: a total of 22 snapshots have been released.

This review will cover the events that occurred during this week, essentially snapshots 0718, 0722, and 0723. As can be seen already from the numbers, there was a slightly longer gap between 0718 and 0722. This is partly due to the weekend, but also because of some issues with the planned SELinux 3.9 upgrade, which needed to be debugged first to understand why certain tests were failing. In between, we have reverted to SELinux 3.8 to unblock the tests and keep rolling, while debugging further in an isolated system (and the SELinux, of course, figured it out, addressed the issue, and resubmitted SELinux 3.9, which will be part of Snapshot 0724)

The most relevant changes published in the three mentioned snapshots were:

• KDE Plasma 6.4.3
• Mesa 25.1.6
• Apache 2.4.64
• cURL 8.15.0
• gpgme 2.0.0
• Linux kernel 6.15.7
• LibreOffice 25.2.5.2
• SQLite 3.50.3

Snapshot 0724 is currently in QA and looks very promising. This snapshot and the near future should bring you these changes:

• SELinux 3.9
• Bash 5.3
• Linux kernel 6.15.8
• Mozilla Firefox 141.0
• GStreamer 1.26.4
• gettext 0.25.1

Table of Contents

• 1) Introduction
• 2) GDM: Polkit Privileges to Modify system-wide Network Settings
• 3) Flatpak: Parental Controls Polkit Action
• 4) ModemManager: CellBroadcast Polkit Action
• 5) cyrus-imapd: Privilege Escalation Attack Vectors from cyrus to root
• 6) systemd-coredump: Change to sysctl Configuration File
• 7) Conclusion

1) Introduction

While most of the SUSE security team members are already enjoying summer time, we want to take a look at the notable things that happened in our team during spring 2025. A couple of major tasks and disclosure processes that we already covered in dedicated posts kept us busy during that time:

• Removal of the Deepin desktop from openSUSE
• Multiple security issues in GNU Screen
• Local privilege escalation in the Kea DHCP server
• Making Gaming work on openSUSE with SELinux enabled
• Remote Denial-of-Service vulnerabilities in sslh

As usual in the spotlight series, we want to give an insight into some of our work beyond these publications: reviews that did not lead to significant security findings, but still kept us busy and in some cases also led to upstream improvements.

This time we will discuss newly added Polkit features in GDM, Flatpak and ModemManager; symlink attack surface in cyrus-imapd and sysctl configuration changes for systemd-coredump.

2) GDM: Polkit Privileges to Modify system-wide Network Settings

Our Gnome Display Manager (GDM) packagers asked us to accept an additional Polkit rule file, which appeared in GDM 48.0. The newly added logic allows the gdm service user to fully control system-wide network settings via the Network Manager D-Bus interface.

The reason for this is a feature in the display manager, which allows to modify network settings from the login screen. We are not completely happy with this change, since it is a rather powerful privilege for a rather exotic use case. The gdm service user is rather powerful anyway, however, and at least it is a well defined privilege that is granted here. Thus we accepted the change.

3) Flatpak: Parental Controls Polkit Action

In version 1.16.1 of Flatpak a new override-parental-controls-update Polkit action appeared. As the action’s name suggests, this is about implementing parental controls on a Linux desktop. The implementation of this feature in Flatpak is a bit peculiar. For example, a Flatpak application with parental control restrictions will first be downloaded and installed, just to be removed again, should parental control policy deny the installation. Also the parental control restrictions are ignored in case the application is already installed and an update is available (this is what the newly added action is about). The reason for this is that Flatpak developers deem it more important to apply security fixes than enforcing parental controls.

While we found no issues with the logic behind this particular Polkit action, we stumbled over an issue in Polkit authentication of both this and an older, related Polkit action override-parental-controls (without the -update suffix). These two Polkit actions are authenticated in an unsafe way based on the Polkit UNIX process subject, in contrast to all the other Polkit actions in Flatpak, which are authenticated based on the D-Bus sender subject. Since this does not affect system security as such, but only application-level policy, we decided to report this issue in the open. We did not get a reaction from upstream about this for a while now, however.

4) ModemManager: CellBroadcast Polkit Action

In ModemManager version 1.24.0 a new org.freedesktop.ModemManager1.CellBroadcast Polkit action appeared. Piecing together the purpose of this action was not all that simple, because documentation and code did not fully add up. We determined the following properties of the cell broadcast API:

• cell broadcast messages are a feature of today’s cellular networks to broadcast emergency messages.
• the ModemManager D-Bus API allows unauthenticated read access to any such messages. This is okay, since these messages are not considered sensitive data.
• the CellBroadcast Polkit action is actually used to protect the deletion of such messages. Only physically present users are allowed to delete them. This is also fine from our point of view.

After we verified the correctness of the use of the new Polkit action, we whitelisted it, so that our packagers could continue submitting their update to openSUSE Tumbleweed.

ModemManager in general has a very complex and continually growing API that makes it difficult to keep track even of incremental changes. That is precisely the reason why we deemed it important to have a deeper look to avoid any unpleasant surprises, especially since ModemManager is running by default in many Linux distributions.

5) cyrus-imapd: Privilege Escalation Attack Vectors from cyrus to root

By way of our regular monitoring of newly packaged systemd unit files, we stumbled over the cyrus-imapd package, which offers an IMAP mail server daemon. We found the package to have three distinct local privilege escalation attack vectors from the cyrus service user to root, which allow to bypass the intended user isolation.

One of the attack vectors is found in a SUSE-specific daily-backup.sh script, which operates as root in the /var/lib/imap state directory (bsc#1241536), owned by cyrus. The script performs chown and chmod operations in there, which would allow a compromised cyrus user to stage symlinks attacks, leading to a local root exploit. We assigned CVE-2025-23394 for this issue and fixed the issue by running this script only with cyrus:mail credentials, instead of root.

The two other attack vectors are found in upstream code, thus we approached upstream and discussed bugfixes and the coordinated release procedure with them. Since the issues only affect defense-in-depth, and are not directly exploitable, we left it up to upstream to decide whether to assign CVEs or not. Upstream considered the issues to be of lower severity and thus no CVEs have been assigned. No formal embargo has been established. The attack vectors are described in the next two paragraphs.

When relying on cyrus-imapd’s built-in privilege drop logic (instead of starting it with lowered privileges right away, e.g. via systemd configuration settings), then the daemon drops privileges only after unsafely operating in /run/cyrus-imapd and
/var/lib/imapd/cores (bsc#1241543). These unsafe file operations allow a compromised cyrus user to create empty world-readable files in arbitrary locations, to truncate arbitrary files, or to enter arbitrary directories that would otherwise not be accessible. Upstream commit 3a0db22f7 ensures that the cores directory is only used after dropping privileges. Furthermore commit 9634fc8311c adds the O_NOFOLLOW flag when creating PID files, to prevent symlink attacks.

While reviewing these upstream bugfixes, we found yet another symlink attack issue, due to a chmod(s->listen, 0777) performed as root, which grants world access to
/run/cyrus-imapd/socket, a path which is again under control of the cyrus service user. When the socket is replaced by a symbolic link, then this can be used for a full local root exploit. This chmod() was only in existence for legacy UNIX systems and upstream thus removed the call in commit 81f342bb902.

6) systemd-coredump: Change to sysctl Configuration File

Our team is also restricting the packaging of sysctl drop-in configuration files e.g. in
/etc/sysctl.d. sysctl configuration settings can have security impact, and their global nature can cause conflicts between packages that have different ideas about what some settings should look like.

We received a change request for the content of the 50-coredump.conf configuration file, which is installed by systemd-coredump. As part of the fix for CVE-2025-4598, the way the coredump handler is installed in the kernel needed to be adjusted.

The change to the file was minimal and well understood, thus we quickly whitelisted the change, to let the bugfixing process proceed.

7) Conclusion

As can be seen from this edition of the SUSE security team spotlight, even smaller and routine review work can lead to interesting insights into upstream projects and possible vulnerabilities. We believe the consistent monitoring of packages and interaction with packagers and upstream projects results in an overall improvement of distribution security, and provides a net profit for the open source community at large.

Install Linux Before It’s Too Late

The openSUSE Project is part of a growing coalition of open-source advocates urging Microsoft users to install a Linux operating system as Microsoft prepares to end support for Windows 10 this October, and urgency to get that message out is building.

Some in the IT industry are suggesting that as many as 50 percent of the devices remain using Windows 10, which comes at great risk to users and businesses.

Those who remain on Windows 10 and don’t upgrade to an operating system providing security and maintenance updates like a Linux OS or Windows 11 will be susceptible to vulnerabilities, malware infections, software incompatibilities, and an increasing amount of system instability and failures over time.

The End of 10 campaign and its initiative aims to promote migration-focused type events to help these users shift from Windows 10 to Linux-based operating systems.

The amount of PCs that will become unprotected on October 14 is unprecedented, and getting people to migrate to Linux operating systems like openSUSE’s is reaching a critical juncture as millions face the looming deadline this Fall.

October 14 is just 12 weeks away and the end-of-support deadline for Windows 10 will expose those who have not migrated to increasing cyber threats.

In additions to the the threats, a big part of the End of 10 movement emphasizes environmental responsibility, digital sustainability and long-term cost savings for those with aging computers that could potentially end up recycled or in landfill.

End of 10 advocates and supporting organizations like NextCloud, REPAIR CAFE, KDE, GNOME, FSFE, EU OS and several other organizations would prefer users find a Linux solution for their older hardware rather than have this event create an environmental disaster. Installing Linux on these old systems can breathe new life into perfectly functional machines that may otherwise be discarded.

Several open-source software projects and organizations and been collaborating for more than a year to create unified resources, tutorials, migration tools and support channels to help lower the barrier to entry for those who seek to install a Linux new operating system.

Members of the openSUSE community and others have been vocal about appealing to Windows 10 users that can’t upgrade their devices to Windows 11.

For those ready to act, the campaign website has resources available and links to community events to help people install Linux.

Anyone who wants to install an openSUSE distribution can follow this A Step-by-Step Guide.

The message to Windows 10 users is clear; don’t replace your computer; reimagine it!

This is part of a series on End of 10 articles where we offer reasons to transition from Windows to Linux.

There are multiple syslog protocols with multiple variants. The new transport(auto) option of the syslog() source in syslog-ng allows you to support all TCP-based variants with a single source driver.

When it comes to syslog, there are many transport options. RFC3164 describes the “legacy” or “BSD” syslog protocol, while RFC5424 refers to the “new” syslog protocol (which is also more than a decade old now… :-) ). RFC5424-formatted messages normally come with framing or octet counting (as per RFC6587), where messages are prefixed with the length of the message. And just to increase confusion even more, some software use RFC5424 message formatting, but without octet counting.

Read more at https://www.syslog-ng.com/community/b/blog/posts/dealing-with-multiple-syslog-protocols-in-syslog-ng-made-easy

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID 'none' 'tpm2-device=auto'

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

Protecting against rogue devices in openSUSE with Full Disk Encryption

openSUSE have now multiple ways to configure a Full Disk Encryption (FDE) installation. A very secure and easy way (YaST2) of doing this is via user space tools, as we described multiple times (like here, here, or here). This solution is based on the systemd tool-set like systemd-cryptenroll, systemd-pcrlock and systemd-cryptsetup, among other, orchestrated by the in-house sdbootutil script.

One of the main advantages of using this systemd approach is the possibility of integrating multiple authentication methods. Together with the traditional password, asked at boot time during the initrd stage, we can now unlock the system using a certificate, a TPM2, or a FIDO2 key. We can mix some of them creating multiple LUKS2 key slots, and use, for example, a TPM2 to unlock the device in a unattended fashion and a FIDO2 key as a recovery mechanism.

Honestly, the TPM2, and the TPM2+PIN variation, are the most relevant ones for the user. As described in the other posts, the TPM2 is a (some times virtual) device that can attest the health of our system using a mechanism known as measured boot.

The tl; dr version of this is that each stage of the boot process, starting from the firmware, will load and “measure” the next stage before delegating the execution on it. For example, this means that there is a moment in the latest stages of the boot process where the UEFI firmware will load from the disk the boot loader into memory. This can be the shim, systemd-boot or grub2-bls. It will calculate a hash value (usually SHA256) and will command to the TPM2 an “extend” operation for one of the internal register (PCR).

The extension is a cryptographic computation that is very easy to calculate, but impossible to replicate. It is done to one of those internal registers (PCR) and consist of calculating the hash (again SHA256) of the old value of the PCR together with the hash of the component that we are measuring. This new value will replace the current PCR value, as is the only way to change those registers. The security property resides in that it is cryptographically impossible to force the write of a desired value on one of those PCRs, but very easy to calculate the final value.

So this means that if all the components of the boot chain process are measured (all the stages in the UEFI firmware, the firmware configuration, the boot loader, the command line, the kernel and even the initrd), the final PCRs values can be compared with our expectations, and discover if the system has been booted with a good known software and configuration, allowing us to instantly known if some component in the boot chain has been hacked or modified with out consent.

That is a powerful property to have, but what is more interesting is that we can have secrets that can only be open in case that we are in one of those good or recognized states. We can, for example, cipher (seal) the key that open an encrypted disk using the TPM2, together with a policy that will decipher (unseal) the same key only, and only if we are using the same TPM2 and the PCR values are on a list of expected ones. Those policies can be very complicated, and can include extra passwords, certificates or other checks that will be validated before the TPM2 can unseal the key.

With a mechanism like this in place, thanks to the systemd tools, we can now avoid entering the password to unlock the encrypted disk if the system is in a healthy state. Healthy in the sense that we cryptographically guarantee that the code and configurations used during the boot process are the expected one, and no one entered init=/bin/bash in our kernel command line, or replaced the kernel or initrd with a vulnerable one, for example.

With the integration that we made of this model in openSUSE, we can make updates of the system, including the boot loader or the kernel, and sdbootutil will transparently generate new predictions of expected PCR values that are now considered safe. This imply an update of the TPM2 policy, that will be taken into consideration for the next boot, so the automatic unlock will succeed. If something goes wrong and the expected PCR values are not meet, the user will need to enter the password that is stored in a different LUKS2 key slot to open the device, to audit the system and validate it.

The fault in the design

Using a TPM2 as described before is a clear increase in the security level, but it is not the final answer. Security is always asymptotic approximation.

Some years ago a physical attack was described for the Windows BitLocker FDE solution. BitLocker is also using the TPM2 in a similar way that was described before, but was not using encrypted session to communicate with the device. Intercepting the SPI bus was shown possible to recover the password that unlock the disk. systemd learned from that and used encrypted sessions early, but this attack can also be avoided if the policy used to unseal the key was also demanding a PIN or password that must be entered by the user. Now the TPM2 can only unseal the secret if the PCRs are in the correct state and the provided password is the correct one. Should be noted that AFAIK the SPI sniffing can work with Clevis.

But more recently a second attack was made public that fully affect the original proposal, and does not requires the sophistication of the original one. (Disclosure: the attack was also internally described independently months before and some counter measurements was put in place much early)

The article describes how that attack can be done checking in the initrd the filesystem UUID used to mount the encrypted device. This information is inside the /etc/crypttab stored in the initrd, that will do something like this:

systemd-cryptsetup attach cr_root /dev/disk/by-uuid/$UUID ‘none’ ‘tpm2-device=auto’

If the expected firmware, configuration files, kernel and initrd are used during the boot process then the TPM2’s PCRs registers will have values that match the policy that unlock the device and the sealed key can be now unsealed by the TPM2, the disk will be unlocked, the switch root will succeed and the boot process will continue in the rootfs.

But what if the original drive is replaced by one that has the same UUID (it is a public information after all) that is also encrypted? Then the PCRs will be in the same correct state. Note that in measure boot is the previous stage the one that measures the next one before delegating the execution. Then systemd-cryptsetup will try to use the TPM2 to unlock the device using the key successfully unsealed by the TPM2 and … will fail to open it, of course. The rogue device maybe have a TPM2 key slot in the LUKS2 header, but for sure cannot be open with this TPM2 nor with the secret password.

In this situation systemd-cryptsetup will ask for the password to unlock the device, and the attacker can enter one that this time will open the rogue device. The switch root will happen but now it will continue the boot process in the fake rootfs, and a program stored there can make questions to the TPM2, that still contains the good PCR values. One of the questions can be the unseal of the secret key using the current policy. And this time (as was done before), the TPM2 will agree to deliver the secret to the bad program. Game over.

There are solutions for this attack, of course.

One is again to use TPM2+PIN instead of TPM2, the same solution for the sniffing attack. In this case the first systemd-cryptsetup call will fail and a password will be asked to unlock the device. But now the bad program cannot ask to the TPM2 to unseal the device using the current policy. The PCR values will match, but the policy also requires the enter of a secret PIN or password known by the real user, and without it the unseal will fail and the key will be keep safe.

Another solution is somehow invalidate the policy, extending some of the PCRs involved before the switch root, so the policy cannot be applied anymore after that. This can be done automatically by systemd-cryptsetup using the measure-pcr=yes in /etc/crypttab. With this option PCR15 will be extended using the volume key, a secret that can only be extracted knowing some of the device keys. For this solution to work, PCR15 needs to be included in the current policy, with an expected value of 0x000..00, the default one. Once the rogue device is open by the hacker provided password, PCR15 will be automatically extended and the value will be different from 0x000..00, invalidating the policy before the switch root.

That is a good solution, but not for us. In the daily situation the user will need to update the system, and a new policy needs to be calculated to replace the old one (for example when the kernel is updated). Because with systemd-pcrlock the policy is stored in the TPM2 in one of the Non Volatile RAM slots (NVIndex), we need to protect it somehow, so it cannot be replaced by other process. For that systemd is storing a secret key (recovery PIN) in a different NVIndex that is sealed by the same policy! If the key cannot be automatically recovered, because the policy does not apply anymore, then the recovery PIN will be asked to the user, making the update process a bit unpleasant if the policy is always invalidated.

Finally, another way to address the issue is to stop the boot process if we detect that the device is not the expected one. We can think of a new service, living in initrd that is executed in the very last moment, just before the switch root, that can stop the boot process (maybe halting the system) if the device that stores the rootfs is not the expected one.

For this, PCR15 is still a good solution. It contains the measurement of a secret (volume key) that can only be known by the real user, and cannot be replicated by the attacker. Ideally we can create a prediction for PCR15 and make this service to compare the effective value with the expected one, and if they are different then it can stop the boot process.

This is what the measure-pcr-validator service from sdbootutil is doing. sdbootutil first generates a prediction for all the encrypted devices that are opened during the initrd, and check that the correct tag is present in /etc/crypttab. To be able to access the volume key, the tool needs the root password, so this prediction is only update when it is really necessary, like for example when a new encrypted device is added. This prediction is signed by a private key stored in the host, as an extra security measurement, but because the public key is also stored in the ESP it is honestly not adding too much.

An extra service (measure-pcr-generator) will put some order on how the encrypted devices are opened, as this order is critical to produce a single possible PCR15 value. If we have one single device the order of measurements is not relevant, but if when have three (rootfs, /home, and swap, for example) we can have six possible and valid different values for PCR15.

The last step is that the dracut-pcr-signature service in the initrd will import from the ESP the prediction, the signature and the public key, so measure-pcr-validator can check the signature and compare the PCR value.

And that is all!

This approach is also kind of similar to what the new systemd-validatefs is doing, but for a file system level.

This blogpost covers only installation of G06 drivers, i.e. drivers for GPUs >= Maxwell, i.e.

• Maxwell, Pascal, Volta (Proprietary Kernel driver)
• Turing and higher (Open Kernel driver)

Check with inxi -aG on openSUSE Leap/Tumbleweed if you have such a GPU. Use hwinfo --gfxcard on SLE. Use G04/G05 legacy drivers (both are Proprietary drivers) for older NVIDIA GPUs.

There are two different ways to install NVIDIA drivers. Either use GFX Repository or use CUDA Repository.

GFX Repository

First add the repository if it has not been added yet. On openSUSE Leap/Tumbleweed and SLE 15 Desktop and SLE 15 Workstation Extension it is being added by default. So check first, if it has already been added.

# openSUSE Leap/Tumbleweed
zypper repos -u | grep https://download.nvidia.com/opensuse/
# SLE
zypper repos -u | grep https://download.nvidia.com/suse

Verify that the repository is enabled. If the output was empty add the repository now:

# Leap 15.6
zypper addrepo https://download.nvidia.com/opensuse/leap/15.6/  nvidia
# Leap 16.0 (Beta)
zypper addrepo https://download.nvidia.com/opensuse/leap/16.0/  nvidia
# Tumbleweed
zypper addrepo https://download.nvidia.com/opensuse/tumbleweed/  nvidia
# SLE15-SP6
zypper addrepo https://download.nvidia.com/suse/sle15sp6/  nvidia
# SLE15-SP7
zypper addrepo https://download.nvidia.com/suse/sle15sp7/  nvidia
# SLE16 (Beta)
zypper addrepo https://download.nvidia.com/suse/sle16/  nvidia

With the following command the appropriate driver (Proprietary or Open Kernel driver) will be installed depending on the GPU on your system. In addition the CUDA and Desktop drivers are installed according to the software packages which are currently installed (Desktop driver trigger: libglvnd package). 

zypper inr

Installation of Open driver on SLE15-SP6, Leap 15.6 and Tumbleweed

Unfortunately in our SLE15-SP6, Leap 15.6 and Tumbleweed repositories we still have driver packages for older Proprietary driver (version 550), which are still registered for Turing+ GPUs. The reason is that at that time the Open driver wasn’t considered stable yet for the desktop. Therefore, if you own a Turing+ GPU (check above) and would like to use the Open driver (which is recommended!) please use the following command instead of the above.

zypper in nvidia-open-driver-G06-signed-kmp-meta

Otherwise you will end up with a Proprietary driver release 550 initially, which then will be updated later to the current version of the Proprietary driver, but not replaced by the open driver automatically.

Understanding package dependancies

The following graphics explains the installation and package dependancies. Zoom in for better reading.

CUDA Repository

Add the repository if it hasn’t been added yet. On SLE15 it might have already been added as aModule. So check first:

# openSUSE Leap/Tumbleweed
zypper repos -u | grep https://developer.download.nvidia.com/compute/cuda/repos/opensuse15
# SLE
zypper repos -u | grep https://developer.download.nvidia.com/compute/cuda/repos/sles15

Verify that the repository is enabled. If the output is empty add the repository now:

# Leap 15.6/16.0(Beta)/Tumbleweed
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/  cuda
# SLE15-SPx/SLE16(Beta) (x86_64)
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/sles15/x86_64/  cuda
# SLE15-SPx/SLE16(Beta) (aarch64)
zypper addrepo https://developer.download.nvidia.com/compute/cuda/repos/sles15/sbsa/  cuda

Use Open prebuilt/secureboot-signed Kernel driver (GPU >= Turing)

In case you have a Turing or later GPU it is strongly recommended to use our prebuilt and secureboot-signed Kernel driver. Unfortunately this is often not the latest driver, which is availabe, since this driver needs to go through our official QA and Maintenance process before it can be released through our product update channels, but things are much easier to handle for the user.

# Install open prebuilt/secureboot-signed Kernel driver
zypper in nvidia-open-driver-G06-signed-cuda-kmp-default

# Make sure userspace CUDA/Desktop drivers will be in sync with just installed open prebuilt/secureboot-signed Kernel driver
version=$(rpm -qa --queryformat '%{VERSION}\n' nvidia-open-driver-G06-signed-cuda-kmp-default | cut -d "_" -f1 | sort -u | tail -n 1)

# Install CUDA drivers
zypper in nvidia-compute-utils-G06 == ${version} nvidia-persistenced == ${version}
# Install Desktop drivers
zypper in nvidia-video-G06 == ${version}

Use Open DKMS Kernel driver on GPUs >= Turing (latest driver available)

If you really need the latest Open driver (also for Turing and later), use NVIDIA’s Open DKMS Kernel driver. This will build this driver on demand for the appropriate Kernel during the boot process.

# Install latest Open DKMS Kernel driver 
zypper in nvidia-open-driver-G06

# Install CUDA drivers
zypper in nvidia-compute-utils-G06

# Install Desktop drivers
zypper in nvidia-video-G06

On Secure Boot systems you still need to import the certificate, so you can later enroll it right after reboot in the MOK-Manager by using your root password.

mokutil --import /var/lib/dkms/mok.pub --root-pw

Otherwise your freshly built kernel modules can’t be loaded by your kernel later.

Use Proprietary DKMS Kernel driver on Maxwell <= GPU < Turing

For Maxwell, Pascal and Volta you need to use the Proprietary DKMS Kernel driver.

# Install proprietary DKMS Kernel driver
zypper in nvidia-driver-G06

# Install CUDA drivers
zypper in nvidia-compute-utils-G06

# Install Desktop drivers
zypper in nvidia-video-G06

Installation of CUDA

In case you used GFX Repository for installing NVIDIA drivers before, first add the CUDA Repository as outlined above in CUDA Repository chapter.

The following commands will install CUDA packages themselves. It describes a regular and minimal installation. In addition it makes it easy to do first tests with CUDA. Depending on which Kernel driver is being used it may be needed to install different CUDA versions.

# Kernel driver being installed via GFX Repo
cuda_version=13-0
# Kernel driver being installed via CUDA Repo
cuda_version=13-0

# Regular installation
zypper in cuda-toolkit-${cuda_version}
# Minimal installation
zypper in cuda-libraries-${cuda_version}

# Unfortunately the following package is not available for aarch64,
# but there are CUDA samples available on GitHub, which can be
# compiled from source: https://github.com/nvidia/cuda-samples
zypper in cuda-demo-suite-12-9

Let’s have a first test for using libcuda (only available on x86_64).

/usr/local/cuda-12/extras/demo_suite/deviceQuery

Which one to choose for NVIDIA driver installation: GFX or CUDA Repository?

Good question! Not so easy to answer. If you rely on support from NVIDIA (especially when using SLE), for Compute usage we strongly recommend to use the CUDA Repository for NVIDIA driver installation. Even if you use NVIDIA Desktop drivers as well.

For others - usually running openSUSE Leap/Tumbleweed - it’s fine to use GFX Repository for NVIDIA driver installation and adding CUDA Repository for installing CUDA packages.

Known issues

CUDA Repository

Once you have added the CUDA Repository it may happen that some old or not recommended driver packages get mistakenly auto-selected for installation or even have already been mistakenly installed. These are:

• nvidia-gfxG05-kmp-default 535.x
• nvidia-open-gfxG05-kmp-default 535.x
• nvidia-open-driver-G06-kmp-default 570.x
• nvidia-driver-G06-kmp-default 570.x
• nvidia-open-driver-G06

In order to avoid mistakenly installing them add package locks for them with zypper.

zypper addlock nvidia-gfxG05-kmp-default
zypper addlock nvidia-open-gfxG05-kmp-default
zypper addlock nvidia-open-driver-G06-kmp-default
# only if you have Turing and higher, i.e. use Open Kernel driver
zypper addlock nvidia-driver-G06-kmp-default
# unless you plan to use the DKMS Open driver package from CUDA repository
zypper addlock nvidia-open-driver-G06

In case you see any of these packages already installed on your system, better read the Troubleshooting section below how to get rid of these and all other nvidia driver packages related to them. Afterwards add locks to them as described right above.

Tumbleweed

On Tumbleweed it may happen that some legacy driver packages get mistakenly auto-selected for installation or even have already been mistakenly installed. These are:

• nvidia-gfxG04-kmp-default
• nvidia-gfxG05-kmp-default

In order to avoid mistakenly installing them add package locks for them with zypper.

zypper addlock nvidia-gfxG04-kmp-default
zypper addlock nvidia-gfxG05-kmp-default

In case you see any of these packages already installed on your system, better read the Troubleshooting section below how to get rid of these and all other nvidia driver packages related to them. Afterwards add locks to them as described right above.

Troubleshooting

In case you got lost in a mess of nvidia driver packages for different driver versions the best way to figure out what the current state the system is in is to run:

rpm -qa | grep -e ^nvidia -e ^libnvidia | grep -v container | sort

Often then the best approach is to begin from scratch, i.e remove all the nvidia driver packages by running:

rpm -e $(rpm -qa | grep -e ^nvidia -e ^libnvidia | grep -v container)

Then follow (again) the instructions above for installing the driver using the GFX or CUDA Repository.