Table of Contents

• 1) Introduction
• 2) Completion of systemd v258 Code Review
• 3) D-Bus Issues in Unreleased plasma-setup KDE Package
  • org.kde.initialsystemsetup.createnewuserautostarthook
  • org.kde.initialsystemsetup.setnewuserhomedirectoryownership
  • org.kde.initialsystemsetup.setnewusertempautologin
  • Upstream Fixes
• 4) Discussion about Granting setgid Privileges to the plocate Binary
• 5) Local Root Exploit in OpenStack’s non-production virtualbmc Project
  • Lack of Authorization and Input Validation in vbmcd
  • Reproducer
  • Further Concerns
• 6) Revisit of the snapd Package Manager
• 7) Conclusion

1) Introduction

The winter season has already begun for most of the people in our team and with the Christmas holidays behind us, which granted us some well-earned rest, we want to take a look back at what happened in our team during the autumn months. During this time we already published a few dedicated review reports:

• trivial local Denial-of-Service in the OpenSMTPD mail transfer agent.
• unauthenticated D-Bus API in the scx scheduler project allowing for a major local Denial-of-Service.
• minor privilege escalation from lightdm to root in lightdm-kde-greeter leading to major improvements of its D-Bus code.
• major local vulnerabilities in the D-Bus interface of smb4k, resulting in upstream fixing a series of long-standing issues in the affected component.

In this post, as usual in the spotlight series, we will look into some topics that did not justify dedicated reports. First we will discuss our continued efforts to review privileged components found in the systemd v258 release, which involved diving deep into some low-level aspects of the Linux kernel API. Section 3 looks at D-Bus issues we found in plasma-setup, a new component for the KDE desktop. Section 4 covers recent discussions about granting special setgid permissions to the plocate package. Section 5 gives insight into security issues found in the virtualbmc OpenStack project, which turned out to be for testing purposes only. Section 6 discusses revived efforts to bring the Snap package manager to openSUSE.

2) Completion of systemd v258 Code Review

We already discussed our systemd v258 review efforts in the previous spotlight edition. At the time we found a local root exploit in the systemd-machined API, which could be fixed before the final release of v258. For the addition of this new major version of systemd to openSUSE Tumbleweed, we still needed to look more closely into a number of other D-Bus and Varlink services that have been added.

During autumn we completed the review of changes in systemd-mountfsd and systemd-nsresourced. Some of the changes introduced with these services allow unprivileged users to perform a number of container-related operations without requiring special privileges.

The io.systemd.MountFileSystem.MountDirectory API call in mountfsd, for example, allows to obtain a mount file descriptor for a directory owned by the calling user, on which a user and group ID mapping is applied corresponding to a user namespace file descriptor also owned by the caller. Some newer, little-known Linux system calls like open_tree() and mount_setattr() are used to achieve this. This niche topic and the low-level nature of the involved APIs result in quite complex code which needed careful reviewing. We are happy to report that we could find no issues in this area, however.

The nsresourced service, among other features, allows unprivileged users to obtain a dynamic range of user and group IDs for use with user namespaces. The tools newuidmap and newgidmap already allowed this for a longer time based on static configuration files. The nsresourced service applies dynamic limits and ID ranges to processes in the system, however, which makes things quite more complicated. This even includes an EBPF program, which keeps track of the uses of the resulting user namespace file descriptors. Despite this complexity we could not find any issues in this component either.

What kept us busy for a longer time was logic invoked by mountfsd to obtain the user and group ID mapping tied to the user namespace file descriptor passed by the unprivileged client. To retrieve this information, the utility function ns_enter_and_pin() forks a short-lived child process which joins the user namespace provided by the client. The parent process then reads the child’s uid_map and gid_map nodes from /proc/<child-pid>.

The mountfsd daemon runs with root privileges (although some sandboxing is applied to it as well), which will be inherited by the short-lived child process. Once the child process joins the user namespace provided by the unprivileged client, the security domain of this process changes, however, because the client owning the namespace is supposed to have full control over processes associated with it.

One consequence of this is that the owner of the user namespace can send arbitrary signals to the short-lived systemd process, e.g. to kill it. This would only result in a kind of Denial-of-Service against the client itself and should not cause any security issues.

We expected another important ramification of this to be in the area of the ptrace() system call. The following is stated in the “ptrace access mode checking” section of the ptrace(2) man page:

(3)  Deny access if neither of the following is true:

            •  The real, effective, and saved-set user IDs of the target
               match the caller's user ID, and the real, effective, and
               saved-set group IDs of the target match the caller's group
               ID.

            •  The caller has the CAP_SYS_PTRACE capability in the user
               namespace of the target.

According to the second item, the unprivileged client, which owns all capabilities in its user namespace, should be able to trace the short-lived systemd process which joins the client-controlled user namespace. This ability would have allowed for an interesting privilege escalation, because tracing capabilities also include the ability to modify the target process, e.g. to change its code and data. While trying to reproduce this, the kernel always denied ptrace() access to this short-lived process, however, and we were not sure why. Unclarity in such aspects is not a good thing when it concerns security, thus we set out to get to the bottom of this.

After diving deep into the Linux kernel’s ptrace() code, we found the commit which is responsible for the rejection of tracing access in this scenario. The background of this commit actually is to prevent owners of unprivileged user namespaces from accessing the executable of processes created in the initial namespace. ptrace() access to the target PID is now only allowed if the target process performed an execve() while being a member of the newly joined user namespace. In summary this means the following:

• if a process only performs fork() and setns() to join a user namespace, then ptrace() access to this process is denied to the owner of the user namespace.
• if a process performs fork(), setns() and execve(), then ptrace() access to this process is granted to the owner of the user namespace.

This detail is not documented in the ptrace() man page and it took us a while to fully understand what was going on. With this well understood we could finally move on, knowing that the logic in mountfsd is robust.

3) D-Bus Issues in Unreleased plasma-setup KDE Package

This new KDE component was first named KISS (KDE initial system setup), but meanwhile has been renamed to plasma-setup. Its purpose is to perform initial system configuration based on a graphical wizard, when a Linux system has been freshly installed.

Our openSUSE KDE packagers asked for a review of this new component, expecting it to be part of a major KDE release in autumn. It turned out that this had not been planned by upstream after all (or plans changed). Still the review we performed turned out to be useful, since we identified various security problems in the existing code which could be fixed by upstream before the new component had seen production use.

The following report is based on the plasma-setup source code as of upstream commit 08ed810e0e7. While the graphical components of plasma-setup run with low privileges, there exists a D-Bus helper service running as root, kde-initial-system-setup-auth-helper, which allows to perform a number of operations with elevated privileges. These operations are guarded by Polkit authorization rules. The dedicated user account kde-initial-system-setup is allowed to invoke any of these actions without authentication. Beyond this, any locally logged-in users are also allowed to invoke the operations without authentication. The latter is quite problematic, as will be outlined below.

The implementation of the D-Bus callbacks for these actions is found in src/auth/authhelper.cpp. The following sub-sections discuss issues in a couple of these actions.

org.kde.initialsystemsetup.createnewuserautostarthook

This action receives a “username” parameter from the unprivileged D-Bus client. The username is not verified by the privileged helper, it only needs to be convertible to QString. The helper then creates all the directory components of /home/<username>/.config/autostart. After this, the file /home/<username>/.config/autostart/remove-autologin.desktop is created and fixed data is written into it.

This action allows local users to create arbitrary world-readable directories owned by root. This can be achieved by passing a string like ../../my/desired/path as “username”. Furthermore, by placing a symlink at the expected location of remove-autologin.desktop, arbitrary files in the system can be overwritten, leading to a local Denial-of-Service.

The implementation of the action also causes the created directories and files to be owned by root:root, and not by the user that actually owns the home directory, which is unclean.

Suggested Fixes

Apart from restricting access to the helper to the kde-initial-system-setup user, the implementation of this action should verify whether the passed-in username actually exists. Furthermore, the home directory of this account should be obtained via the getpwent() API, instead of assuming that /home/<username> will always be the correct home directory.

When the execution of this helper is actually limited to the initial setup context, it could be technically acceptable to operate as root in the newly created user’s home directory. For reasons of prudence and giving a good example, we still recommend to drop privileges to the target user account before actually writing the .desktop file in the user’s home directory.

org.kde.initialsystemsetup.setnewuserhomedirectoryownership

The method call associated with this action also receives a “username” parameter which is not verified. The following command line is invoked based on the “username” parameter:

chown -R <username>:<username> /home/<username>

This is on the verge of a local root exploit, save for the fact that chown expects a valid user and group account to give the ownership to, which at the same time needs to result in the proper path to operate on. A username containing path elements will fail, because the necessary characters like / are by default denied in usernames.

This action still allows to potentially change ownership of all files of arbitrary other users’ home directories. Fortunately the recursive chown algorithm is not subject to symlink attacks these days. If somebody would be able to place a symlink in place of their home directory in /home/<username>, then the symlink would still be followed, however.

The username could also be interpreted as an arbitrary command line argument to chown, thwarted only by the fact that the <username>:<username> argument is constructed here instead of just passing <username>, which will prevent proper command line arguments from being passed.

Suggested Fixes

As for the previous action, the implementation should verify if the username is valid and determine the proper home directory and group via getpwent(). The assumption that username and group are equivalent is also problematic here.

Why this operation would be needed at all for a newly created home directory is questionable. When new user accounts are created, file ownership should already be correct. If this action is supposed to fix the ownership of files created by other plasma-setup actions in the home directory as root (as is seen in the createnewuserautostarthook action), then this is only a hack which should be removed in favor of not creating files as root in unprivileged users’ home directories in the first place.

org.kde.initialsystemsetup.setnewusertempautologin

Again this method receives a “username” parameter which is not verified. The implementation writes the following content to the file /etc/sddm.conf.d/99-kde-initial-system-setup.conf:

[Autologin]
User=<username>
Session=plasma
Relogin=true

This SDDM configuration snippet is supposed to automatically login the given user account. For some reason that we did not investigate more deeply, the configuration was not effective during our tests on openSUSE Tumbleweed. We could verify that the configuration file created this way was parsed and evaluated in SDDM, however, so something else must have been amiss.

The automatic login is supposed to work, though, and if it does, then any local user account can call this action with root as username, which should cause an automatic login of the root user the next time SDDM runs.

By passing crafted strings for “username”, the content of the drop-in configuration file can even be fully controlled by local users. The following “username” would create a General section with a crafted “RebootCommand”, for example:

user\n[General]\nRebootCommand=/home/myuser/evil

Provided the configuration snippet is actually in effect in SDDM, this action allows for a local root exploit.

Suggested Fixes

As for the other actions, the implementation should verify whether the passed “username” is valid and does not equal root.

Upstream Fixes

We privately approached KDE security on 2025-09-22 with a detailed report about these findings. As a result we established contact with the plasma-setup developer and discussed fixes for the issues. It was decided to perform the bugfix in the open, since the component was not yet part of a stable release of KDE. We reviewed an upstream merge request during the course of two weeks and upstream managed to arrive at a much improved version of the KAuth helper component.

As of commit e6eb1cd9a8d the privileged helper carefully scrutinizes the input parameters received via D-Bus, and it also drops privileges to the calling user before operating in the unprivileged user’s home directory. Also the KAuth actions provided by the helper are now restricted to the plasma-setup service user and no longer accessible to all locally logged-in users. The latter would still be problematic, since it would allow to setup automatic login for arbitrary other users in the system, for example.

4) Discussion about Granting setgid Privileges to the plocate Binary

An openSUSE community member approached us about granting special setgid privileges to the plocate binary. plocate is a modern and fast replacement for the classic locate program. Upstream supports operation of the plocate program with the setgid bit assigned to the plocate group. This means that the program is granted plocate group privileges during execution.

When updatedb, locate’s utility for indexing files, would be invoked with full root privileges, then the database in /var/lib/plocate would contain information about all files in the file system. This way locate would grant all users in the system read access to this information, resulting in an information leak, because users can see paths that they would not normally be allowed to list, like all the files stored in the /root home directory. For this reason the plocate-updatedb system service on openSUSE Tumbleweed runs as nobody:nobody, resulting in a system-wide plocate database which only contains information about publicly accessible paths in the system. For being able to locate their own private files, users need to create their own user-specific databases instead.

The purpose of the setgid privilege is to address this locate database access issue. plocate supports a mode in which updatedb is invoked with full root privileges, but the ownership of the central database is changed to root:plocate and file mode 0640. When plocate is installed as setgid-plocate then it is still allowed to access the central database. The program drops the special group credentials quickly again, right after opening the database. The program then ensures that the calling user will only be able to retrieve information about files that it is allowed to access based on its real credentials.

There is a minor security issue found in this approach. Since the plocate database does not contain metadata about the files it indexed, the plocate program needs to check the ownership of files in the file system at the time the search query runs. This is a sort of a TOCTOU (time-of-check time-of-use) race condition. There can be situations when the verification in plocate yields wrong results:

root# mkdir --mode=1777 /shared
root# mkdir --mode=0700 /shared/secret-dir
root# touch /shared/secret-dir/secret-file
root# updatedb

# root will be able to locate any files in secret-dir
root# locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

# non-root cannot locate the secret-file
user$ locate /shared/se
/shared/secret-dir

# now consider root deletes the secret-dir again
root# rm -rf /shared/secret-dir

# now the unprivileged user takes ownership of this path
user$ mkdir --mode=0755 /shared/secret-dir

# this only works before `updatedb` is called again, because then it will
# notice that secret-file no longer exists and delete it from the database.
#
# when the unprivileged user calls locate this time, the secret-file will show
# up, since the "secret-dir" is now controlled by the unprivileged caller.
user$ locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file

This problem likely cannot be easily fixed in the plocate code, since it would require changing the database format radically, increasing database size as a result, only to fix an unlikely problem.

The information leak is minor and should rarely be exploitable. For this reason we left it up to the openSUSE plocate package maintainer whether the setgid-plocate approach should be used, or not.

5) Local Root Exploit in OpenStack’s non-production virtualbmc Project

By way of our efforts to monitor newly introduced systemd services in openSUSE Tumbleweed, the python-virtualbmc package caught our attention. The program allows to emulate a board management controller (BMC) interface for use with libvirt.

Part of the package is a daemon running with full root privileges, listening for ZeroMQ API requests on localhost. A number of unauthenticated API calls in this context raised our suspicions, which is why we scheduled a full review of this package. A closer look showed that the unauthenticated API calls were indeed problematic, even allowing for a full local root exploit.

We filed a detailed private bug report on LaunchPad for the OpenStack project, but had difficulties getting a response. After some weeks we reached out to an individual member of the OpenStack security team and learned from the reply that the virtualbmc project was not intended for production use at all, but is rather a utility intended for use in testing environments. This is also documented in the repository’s README, which was overlooked by us. As a result we filed a delete request for the python-virtualbmc package in openSUSE Tumbleweed, and the package has already been removed.

For completeness, a detailed report of the security issues in the virtualbmc daemon follows below.

Lack of Authorization and Input Validation in vbmcd

When the virtualbmc systemd service is started, then /usr/bin/vbmcd runs with full root privileges. It offers a ZeroMQ-based network API, listening on localhost port 50891 by default. Any local user in the system can talk to the daemon this way.

A simple request which can be sent to the daemon (in JSON format) is the following stop command, for example:

{
        "command": "stop",
        "port": 1234,
        "domain_names": ["../../home/myaccount/mydomain"],
}

The domain_name passed here will be used by the daemon to lookup a supposedly trusted per-domain configuration file, which is by default located in /root/.vbmc/<domain>/config. Since the daemon does not scrutinize the input domain_name, a local attacker can include directory components in the name, to trick the daemon into accessing an attacker-controlled configuration file.

In the context of the stop command used here, the daemon will try to update the domain’s configuration file in case a change of domain state is detected. The path for writing out the updated configuration file will be constructed using the domain_name found in the input configuration file. Thus the local attacker can place data like this into /home/myaccount/mydomain/config:

[VirtualBMC]
domain_name = ../../etc/sudoers.d
port = 1234
active = true
address = some
  evil stuff
  myaccount ALL=(ALL:ALL) NOPASSWD: ALL

The daemon will now believe that the domain’s state changed, because the input configuration file contains active = true, while the daemon was asked to stop the domain. This will trigger logic to write out an updated configuration file with the new state of the domain configuration. The logic for this is found in the _vbmc_enabled() member function.

Since the domain_name found in the crafted configuration file is set to ../../etc/sudoers.d, the daemon will write the new configuration file into /root/.vbmcd/../../etc/sudoers.d/config. To get an advantage from this, the attacker must get the daemon to write out at least one valid sudoers configuration line into the new configuration file.

The attacker has only a limited degree of freedom at this stage, because the daemon will write out the new configuration file via the Python configparser module and will only consider the [VirtualBMC] section as well as any of the configuration keys listed in the VBMC_OPTIONS list defined in the daemon’s code.

To help with the exploit, the configparser multiline syntax comes to the rescue: any lines following an assignment which are indented will be accepted as part of the configuration value. When writing the settings out to a new configuration file, these multiline settings will be preserved. This is put to use in the example above, which contains a final line myaccount ALL=.... This line will now appear along with the rest of the configuration data in /etc/sudoers.d/config.

As a result, when the attacker now invokes sudo su -, a couple of sudoers parsing errors will appear, but in the end, access is granted and a root shell will be obtained by the attacker.

This approach of using a sudoers drop-in configuration file is just one of the more obvious approaches that came to mind. There’s a lot of different ways to exploit this, however, for example by overwriting shell scripts or script snippets in /etc or /usr/bin and then waiting for a privileged process to run them. This would be even easier, because shell scripts have less strict syntax requirements compared to the sudoers configuration file. The effect would not be immediate, however, like in the sudoers approach.

Reproducer

We offer a Python script for download, which is a Proof-of-Concept (PoC) to reproduce the local root exploit in the context of an arbitrary unprivileged user on the system, when vbmcd is running with its default configuration. sudo needs to be installed, naturally, for the exploit to work.

Further Concerns

In general, the API offered by vbmcd on localhost is missing input sanitization and authorization. Authorization seems only to be performed indirectly via libvirt. In this context clients can also pass crafted libvirt_uri parameters, for example, which seem to make it possible to let the daemon connect to arbitrary URLs via SSH. There also is no isolation between different users’ domain configurations, e.g. the “stop” command used above can be issued for any domain configured by another user in the system.

To make this API safe, we believe there needs to be an ownership model for each domain’s configuration, a verification of the client’s credentials in some form (a UNIX domain socket would allow this more easily) and sanitization of all input parameters to avoid any unexpected side effects.

Since the daemon listens on an unprivileged port on localhost, other unprivileged users can try to bind to this port first and provide a fake vbmcd service. Since the API requests can also contain secret credentials, this would pose a major local information leak. For safe operation, the API would need to bind to a privileged port on localhost instead.

6) Revisit of the snapd Package Manager

In 2019 we received a request to add the snapd package manager to openSUSE, which involved a review of the setuid-root program snap-confine. At the time we were generally satisfied with the code quality and design of the program, but still found a few low to medium severity security issues and gave recommendations on how to improve the code in some spots. The packagers have meanwhile been busy with other topics and we never saw an updated openSUSE package containing the necessary changes, which is why we closed the related bugs after a period of inactivity.

In August we received a follow-up request for addition of an updated snapd package. We revisited the privileged components and again provided feedback to upstream. This time all remaining issues could be resolved and the new package has been allowed to become part of openSUSE Tumbleweed. We are happy to see these old efforts not going completely to waste, and welcome the possibility to use Snap packages on openSUSE Tumbleweed in the future.

7) Conclusion

Again we hope we’ve been able to give you some additional insight into our efforts to maintain the security of SUSE distributions and open source software. We are looking forward to the next edition of the spotlight series, which will be published in about three months from now.

While testing the latest Elasticsearch release with syslog-ng, I realized that there was already a not fully documented elasticsearch-datastream() driver. Instead of fixing the docs, I reworked the elasticsearch-http() destination to support data streams.

So, what was the problem? The driver follows a different logic in multiple places than the base elasticsearch-http() destination driver. Some of the descriptions were too general, others were missing completely. You had to read the configuration file in the syslog-ng configuration library (SCL) to configure the destination properly.

While preparing for syslog-ng 4.11.0, the OpenSearch destination received a change that allows support for data streams. I applied these changes to the elasticsearch-http() destination, and did a small compatibility change along the way, so old configurations and samples from blogs work.

Read more at https://www.syslog-ng.com/community/b/blog/posts/changes-in-the-syslog-ng-elasticsearch-destination

A photo posted to Reddit and followup media coverage about computers being discarded in large amounts due to software policies should ignite public concern on the use of taxpayer money being used responsibly.

The image shows a large pallet of PCs that were thrown out because they were not upgraded to a newer operating system.

The post highlights a growing concern among critics of government technology policy where public hardware is being retired not because it has failed, but because it no longer aligns with policy requirements.

Seeing stacks of computers that are still capable of using Linux operating systems like openSUSE and others raises a lot of questions about how tax money is being spent, especially in a country with uncontrollable runaway debt ($38.6 trillion at the time of publication). Migrating to open-source solutions could be an easy win for cost savings and government efficiency. The Government Accountability Office (GAO) report notes the federal government spends more than $100 billion annually on IT and cybersecurity, which includes thousands of software licenses that do not isolate Windows alone.

Extended support for Windows 10 ends on Oct 13, 2026, according to endof10.org. End of 10 is an information campaign focusing on reducing unnecessary e-waste driven by software policy decisions.

The image illustrates how public policy choices can contribute to waste of taxpayer funds even when they appear in the form of discarded hardware. Serviceable computers are being retired not because they are broken, but because public institutions are locked into closed, inflexible software decisions.

Advocates for fiscal responsibility can point to Europe’s Public Money, Public Code principle, which is championed by the Free Software Foundation Europe, as an example to emulate. The Public Money, Public Code effort began as an information campaign that argued publicly funded software should remain open, adaptable and reusable, which extends the useful life of public hardware.

Supporters of the approach say open, publicly owned code can reduce costs by allowing agencies to reuse software rather than rebuilding similar systems repeatedly. They also argue that shared development spreads costs across governments, improves transparency through independent review, and extends the useful life of computer hardware.

A Federal Source Code Policy directed US agencies in 2016 to release at least some custom code as open source, but it has not mandated an “open-by-default” approach to mirror the logic of Public Money, Public Code.

This lack of policy further extends government debt and enriches shareholders through transferring wealth from the taxpaying public to private equity shareholders.

Though the Public Money, Public Code campaign originated in Europe, its goals can resonate with the taxpaying voter and it is a more responsible approach for the environment and usage of taxes. Environmental advocates like Joanna Murzyn, who spoke at the KDE Akademy conference in 2024, warns about the increasing problem of electronic waste (e-waste). Analysts are estimating that tens of millions of PCs are being scrapped as a result of software lifecycle decisions, which are equally reflected in government policies.

E-waste, which includes discarded laptops, desktops and other electronics, releases toxic substances like lead, mercury and cadmium into the environment, according to Murzyn. These substances can contaminate soil and water as well as cause long-term harm to ecosystems and human health. Murzyn urged people to resist the urge to “upgrade” to new hardware and instead explore solutions like Linux that extend the life of existing devices.

Join End of 10 to learn how extending the life of existing computers can reduce waste, lower public costs and promote more responsible technology policies.

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

I started with this page today! Currently only one article and I wish one article per month. I prefer do not describe game before I end it, but I known it is not possible.

So, check it out: https://futureofgamming.com.

Page will be created in Polish, maybe seldom text in English.

Opublikowałem tę stronę dzisiaj. Obecnie tylko jeden artykuł, postaram się jeden na miesiąc. Wolę nie opisywać gry, zanim ją skończę. Wiem, że to nie możliwe.

Sprawdź: https://futureofgamming.com.

Strona będzie prowadzona w języku Polskim, może okazjonalnie zamieszczę jakiś tekst w języku Angielskim.

Dear Tumbleweed users and hackers,

The holiday lull is over, and Factory is buzzing again. Developers and packagers are back in force, pushing a steady stream of submissions our way. As always, every change is carefully reviewed, staged, tested, and evaluated before release. The result: just under 500 submissions processed in a single week, shipped across five snapshots — 0102, 0103, 0105, 0106, and 0108.

The most relevant changes released this week include:

• SDL 3.4.0
• ALSA 1.2.15.1
• xfsdump 3.2.0
• xterm 406
• Inkscape 1.4.3
• Ruby 4.0 — all ruby34-rubygem-* packages have been removed in favor of the new ruby40-rubygem-*
• Linux kernel 6.18.3
• GNOME 49.3 components — as usual for a .3 release, only components with noteworthy fixes were updated
• Mesa 25.3.3
• ncurses 6.6
• cURL 8.18.0

The staging projects are currently well populated, with the following updates under test:

• transactional-update 6.0.3
• Linux kernel 6.18.4
• KDE Gear 25.12.1
• xz 5.0.2
• run0-wrapper, available as an optional sudo replacement

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 are from Jan. 3 to Jan. 8.

Blogs this week focus on responsible use of AI, updates for KDE, security disclosures in the openSUSE ecosystem, and practical guidance for users and administrators. Topics range from Plasma accessibility improvements and new KDE apps to in-depth looks at Linux kernel security, high-availability architectures, and major openSUSE upgrades.

Here is a summary and links for each post:

First Update for KDE Gear 25.12 Released

The KDE Blog reports the release of KDE Gear 25.12.1. This update resolves issues in core applications like Dolphin and Kate. Dolphin has support for migrating old session files and a crash fix in Kate’s Project plugin tree view was made.

Just Say No to AI Everywhere

A blog from Victorhck urges caution against the uncritical adoption of artificial intelligence across all domains of life and technology. The post argues that while AI tools may offer convenience, they can come at the cost of autonomy and transparency. The post points out that many products now embed AI with little transparency, and urge readers to keep technology human-centered, open, and ethical. He encourages critical reflection on where these tools should and shouldn’t be used.

New Digital Whiteboard App “Drawy” This Week in KDE Apps

The KDE Blog highlights the release of Drawy, a new digital whiteboard application developed as part of KDE Apps. The app focuses on simplicity and ease of use, making it suitable for both casual users and productivity workflows. Drawy joins the KDE Apps ecosystem as a lightweight tool that complements Plasma’s creative and note-taking capabilities.

Free Software Foundation January 2026 News Roundup

Victorhck posts collective highlights from the Free Software Foundation’s monthly newsletter and summarizes key updates on free software advocacy. Featured news includes the winners of the Free Software Awards, historic private donations to the FSF, and a piece on digital freedom and user rights.

TLP Polkit Authentication Bypass Vulnerability Disclosed (CVE-2025-67859)

The Security Team reports a critical authentication bypass flaw in TLP version 1.9.0’s new profiles daemon, which uses Polkit for D-Bus authorization. Due to unsafe use of the deprecated “unix-process” Polkit subject, local users can bypass authentication and gain unauthorized control over power profiles and logging settings. Upstream released TLP 1.9.1 with coordinated fixes to strengthen the authentication flaw.

Foomuuri Firewall Manager Fixed: D-Bus Authorization and Input Validation Flaws (CVE-2025-67603, CVE-2025-67858)

The Security Team was busy again disclosing that the Foomuuri firewall manager prior to version 0.31 had a privileged D-Bus service with no client authorization or thorough input verification, letting any local user modify the firewall configuration. The issues are resolved in Foomuuri 0.31 through the addition of Polkit-based authentication, strict input sanitization, and systemd hardening measures.

openSUSE 15.6 to 16.0 Upgrade Notes

This blog offers detailed, hands-on notes and tweaks for upgrading from openSUSE Leap 15.6 to the new 16.0 release using zypper and related tools. The post covers handling vendor changes, resolving a post-upgrade black screen (fixed by manually starting Plasma on Wayland), and cleaning up orphaned or unneeded packages. It also includes tips for restoring power management, fixing X11 and screen-sharing support, migrating Dolphin service menus, and updating Ruby from 2.5 to 3.4.3.

Kraft 2.0 Released: Major Update for Invoicing on Linux

Klaas Freitag announces Kraft 2.0.0,a major update to the Linux invoicing and document management app for small businesses. This version updates Kraft to Qt6 and KDE Frameworks 6, migrates from a relational database to storing documents as XML files on the filesystem, enabling future sync with private clouds like like OpenCloud or Nextcloud and supports distributed workflows.

Run Command Plasmoid: Execute Commands Directly from Your KDE Desktop (Plasma 24.08)

The KDE Blog introduces the Run Command plasmoid, a new widget in KDE Plasma 24.08 that lets users execute terminal commands without opening a console. You can customize the icon, label, and the actual command that the plasmoid will execute, making it a handy shortcut for frequent tasks.

pgtwin as OCF Agent

Azouhr’s Blog introduces pgtwin, a new OCF (Open Cluster Framework) agent designed for managing PostgreSQL high availability in Pacemaker/Corosync clusters—particularly in dual-datacenter setups like those used with Linux on IBM Z and Kubernetes via k3s-io/kine. The post walks through key design concepts such as physical replication with slots, automatic standby initialization, and fast failover using pg_rewind. It also touches on replication health monitoring and configuration validation that helps maintain robust HA operations.

What Is Linux? The Only Video You Need to Understand It

The KDE Blog shares an educational video that explains what Linux really is (and isn’t), clearing up common confusion about kernels, distributions, and GNU/Linux basics. Created with AI-assisted editing, it’s designed as a go-to resource for newcomers or anyone needing to explain Linux clearly and visually.

What Does It Mean to Write in 2026?

Cornelius Schumacher’s Blog reflects on the evolving purpose and value of writing in an age dominated by algorithmic content distribution and AI-generated text. He questions the impact of AI-generated content and reaffirms his commitment to thoughtful, truthful writing as a means of connection, memory, and community—values he believes remain essential even as tools and platforms change.

An LLM or Large Language Model Cannot Lie

A post from Victorhck argues that large language models (LLMs) do not “lie” in the human sense because they lack intention, beliefs, or awareness. Instead, apparent falsehoods stem from statistical pattern generation based on training data, not deliberate deception. The post emphasizes the importance of precise language when discussing AI behavior to avoid anthropomorphizing models and to foster clearer public understanding of their capabilities and limitations.

Akademy 2026 to Be Held in Graz, Austria

The KDE Blog announces that Akademy 2026—the annual KDE community conference—will take place in Graz, Austria. The event will bring together contributors, developers, artists, and users for talks, workshops, and collaboration around KDE software.

openSUSE Tumbleweed Weekly Review – Week 1 of 2026

Victorhck and dimstar summarize the first week of 2026 for openSUSE Tumbleweed. Key package updates include Python 3.13.11 (with CVE fixes), libgit2 1.9.2, Harfbuzz 12.3.0, NetworkManager 1.54.3, GStreamer 1.26.10, VLC 3.0.22/3.0.23, GPG 2.5.16, and upower 1.91.0. Upcoming releases in the pipeline feature SDL3 3.4.0, Ruby 4.0, transactional-update 6.0.1, and Shadow 4.19.0.

New Year, New Accessibility Features: This Week in Plasma

The KDE Blog showcases recent accessibility improvements in KDE Plasma. New features include refined screen reader support, better keyboard navigation in system settings, and improved high-contrast theme consistency across applications.

Path-Aware High Availability (PAHA)

Azouhr’s Blog introduces Path-Aware High Availability (PAHA), a novel clustering paradigm that shifts focus from mere process uptime to actual service usability. The author explains how PAHA complements traditional heartbeat mechanisms by reacting intelligently to path-specific outages rather than generic node failures. Practical examples and design principles are given on how PAHA can reduce unnecessary failovers and improve overall system uptime.

Seamless Windows Apps on openSUSE with WinBoat

CubicleNate explores how WinBoat, an open-source container-based tool, lets you run Windows applications on openSUSE Tumbleweed with seamless desktop integration using Docker/KVM and FreeRDP. After resolving network conflicts (Docker subnet overlap), adjusting Docker’s address pool, and modifying the docker-compose.yml to enable USB passthrough and home directory sharing without privileged mode, he achieved near-native app behavior on KDE Plasma with Wayland. It delivers near-native behavior for specific Windows-only tools without dual-booting or a separate Windows PC.

KDE Blog Seeks Community Collaboration

The KDE Blog has issued a call for contributors to help sustain and enrich its Spanish-language coverage of KDE and Free Software news. The blog invites writers, translators, and enthusiasts to submit articles, summaries, or news about Plasma, applications, events like Akademy, or general open-source developments.

Linux Kernel Security Work – January 2026 Update

Greg Kroah-Hartman’s Blog provides a monthly summary of ongoing Linux kernel security maintenance efforts. In December 2025, the stable and long-term kernel trees received numerous fixes, including patches for memory corruption, use-after-free vulnerabilities, and privilege escalation flaws across various subsystems.

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

Table of Contents

• 1) Introduction
• 2) Overview of the D-Bus Service
• 3) Security Issues
  • 3.1) Lack of Authentication / Polkit Authentication Bypass
  • 3.2) D-Bus Methods Allowing Privilege Escalation
• 4) Suggested Fixes
• 5) Upstream Bugfixes
• 6) CVE Assignment
• 7) Coordinated Disclosure
• 8) Timeline
• 9) References

1) Introduction

InputPlumber is a utility for combining Linux input devices into virtual input devices. It is mostly used in the context of Linux gaming and is part of SteamOS.

An openSUSE community member packaged InputPlumber which required a review by the SUSE security team, as it contains a D-Bus system service. The first version of InputPlumber we reviewed was completely lacking client authentication, causing us to reject it. A follow-up version contained Polkit authentication, which turned out to be lacking in multiple regards. At this point we approached upstream with a detailed report and established coordinated disclosure. Starting with version v0.69.0 of InputPlumber most (but not all) of the issues in this report have been addressed. SteamOS also published new images for version 3.7.20 containing the fixes.

This report is based on InputPlumber release v0.67.0. The next section provides an overview of InputPlumber’s D-Bus service. Section 3 looks into the security issues in detail. Section 4 discusses the fixes we suggested to upstream. Section 5 looks into the upstream bugfixes to address the issues and aspects that remain unfixed. Section 6 covers the CVE assignments we did for the issues we found. Section 7 provides a summary of the coordinated disclosure process we followed for this report.

2) Overview of the D-Bus Service

InputPlumber is implemented in Rust and the size of the code base is surprisingly high for this type of project, adding up to about 50,000 lines of code overall (not counting vendor code) and about 3,000 lines dedicated to the D-Bus API specifically.

The InputPlumber D-Bus service runs with full root privileges, offering the “org.shadowblip.InputManager” interface on the D-Bus system bus. Additionally various interfaces representing Linux input devices are provided by the daemon, like a keyboard interface. In summary the service provides around 90 different D-Bus properties and about 10 different interfaces on various objects exported by it. The Polkit policy lists over 100 different actions, controlling every aspect of the D-Bus API including read/write access to individual properties.

3) Security Issues

3.1) Lack of Authentication / Polkit Authentication Bypass

Initially we looked into InputPlumber version v0.62.2. In this version there is no Polkit authorization at all for the D-Bus interfaces. There are also no restrictions in the configuration of the D-Bus service, allowing all users in the system to connect to it, even low privilege user accounts like nobody.

We thought about reaching out to upstream already at this point, when we noticed that in InputPlumber version v0.63.0 (which was meanwhile published on GitHub) Polkit authentication had been added via commit 0a80f3d85. Thus we asked our community maintainer to update the package to at least that version for us to have another look.

Due to other priorities we only got around to taking a fresh look at the package at a later time, when the package had already been updated to version v0.67.0, on which this report is based.

Looking into this version we first discovered that the Polkit authentication was still not effective in the package build provided to us. The reason for this was that Polkit support was only a compile-time feature on Rust Cargo configuration level - which was disabled by default. We believe that in this version there is also no canonical way to enable the feature when using the Makefile found in the repository. For this reason we created our own build of InputPlumber and applied a patch to hard-enable the Polkit feature for testing.

In this custom package build of InputPlumber the Polkit authentication triggered as expected. While looking into the implementation of the Polkit authentication wrapper, however, we noticed that the Polkit authentication logic uses the “unix-process” Polkit subject in an unsafe way. It retrieves the caller’s PID from the D-Bus connection and passes this information on to the Polkit daemon. This suffers from a race condition, because the client can attempt to have its PID replaced by a privileged process by the time polkitd gets around to actually look at the credentials of the process.

This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.

In summary none of the versions of InputPlumber we looked into provided sufficient authentication, even if integrators would have managed to actually enable the Polkit layer in versions v0.63.0 and later. Thus all InputPlumber D-Bus methods can be considered accessible by all users in the system without authentication.

3.2) D-Bus Methods Allowing Privilege Escalation

Considering the unprivileged access to the D-Bus methods provided by InputPlumber, the following two methods quickly caught our attention as being problematic:

CreateCompositeDevice(in s config_path)

This method parses the provided input path as YAML to create a CompositeDevice configuration and suffers from the following issues:

• The method allows to perform file existence tests, by passing paths usually not accessible to the caller.
• The method allows for a local Denial-of-Service (e.g. by passing /dev/zero as input file, leading to memory exhaustion in InputPlumber).
• The method allows for an information leak, e.g. from /root/.bash_history:

  user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
      -m org.shadowblip.InputManager.CreateCompositeDevice /root/.bash_history
  Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Unable to deserialize: invalid type: string "cd /etc/polkit-1/rules.d/", expected struct CompositeDeviceConfig at line 2 column 1
  

  The string cd /etc/polkit-1/rules.d is an entry from root’s history file in this case.

CreateTargetDevice(in s kind)

This method allows to create a virtual keyboard input device like this:

user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
   -m org.shadowblip.InputManager.CreateTargetDevice keyboard

Once the virtual keyboard has been created, key presses can be injected into the active user session (login terminal or graphical desktop) like this:

user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/devices/target/keyboard0 \
    -m org.shadowblip.Input.Keyboard.SendKey KEY_R true

All supported key symbols are found in keyboard.rs. Using this ability, any user in the system can inject input to an active desktop session or the active login terminal screen, possibly leading to arbitrary code execution in the context of the currently logged in user, if any.

4) Suggested Fixes

We suggested the following action items to upstream to improve the security of the InputPlumber D-Bus API:

• Use of the “system bus name” Polkit subject to fix the authentication code.
• Enabling of Polkit authorization by default in the build process.
• Passing of file descriptors instead of path names to D-Bus methods. This way the complexity of safely accessing client-provided paths is avoided and various attack scenarios in this area are no longer relevant.
• Addition of documentation pointing out that unauthorized access to the D-Bus service has security implications.
• Addition of hardening to the inputplumber systemd service. By using settings like ProtectSystem=full the service can be tightened to avoid any unexpected side effects when things go wrong at the first line of defense.

5) Upstream Bugfixes

Upstream mostly followed our suggestions and fixed the issues as follows:

• in commit 4db3b20 the Polkit subject used for authentication has been switched to “system bus name”, therefore fixing the Polkit authentication bypass.
• in commit f3854be the “Polkit” Cargo feature is enabled by default.
• in commit 79f0745 systemd hardening is applied to the InputPlumber service.

All of these fixes are contained in InputPlumber version v0.69.0 and later.

Upstream initially wanted to avoid breaking the D-Bus API by switching to file descriptors instead of path names, as we suggested. We strongly recommended to do this, however, to avoid various issues that can occur when clients pass malicious file paths. An upstream developer then created a pull request which introduces file descriptors in the API. We provided feedback that this is going in the right direction, but suggested to also perform checks on the file descriptors passed by clients to make sure they refer to regular files and have no unusual open flags like O_PATH set.

At the time of publication of this report we noticed that the improvements of the D-Bus API to use file descriptors have not been merged yet and are not available in a release. Thus some aspects of the issues described in this report remain unaddressed, although they are now at least protected by proper Polkit authentication. Sensitive methods like CreateCompositeDevice also require admin privileges to be called, thus these are mostly defense-in-depth issues, or only relevant when integrators or admins relax Polkit authentication requirements.

6) CVE Assignment

In agreement with upstream we performed the following CVE assignments corresponding to this report:

• CVE-2025-66005: lack of authorization of the InputManager D-Bus interface in InputPlumber versions before v0.63.0 can lead to local Denial-of-Service, information leak or even privilege escalation in the context of the currently active user session.

• CVE-2025-14338: Polkit authentication disabled by default and a race condition in the Polkit authorization check in versions before v0.69.0 can lead to the same issues as in CVE-2025-66005.

7) Coordinated Disclosure

We informed upstream about the security issues on 2025-11-25 and offered coordinated disclosure. Upstream quickly confirmed the issues and agreed to follow coordinated disclosure. The developers discussed bugfixes with us, which they provided in public GitHub pull requests. This way the information about the issues was not fully private anymore, but we agreed to keep the full report private for a longer time, until new SteamOS images would be published, containing a fixed InputPlumber.

We found out only at the time of publication that not all aspects of the issues have been addressed in the bugfix release.

We want to thank the InputPlumber developers for their cooperation regarding this report.

8) Timeline

9) References

• InputPlumber GitHub project
• InputPlumber Bugfix Release v0.69.0
• SteamOS Images 3.7.20 Beta containing a fixed InputPlumber

Table of Contents

• 1) Introduction
• 2) Overview of the TLP Daemon
• 3) Security Issues
  • 3.1 Polkit Authorization Check can be Bypassed
  • 3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds
  • 3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception
  • 3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface
• 4) CVE Assignment
• 5) Coordinated Disclosure
• 6) Timeline
• 7) References

1) Introduction

TLP is a utility for saving laptop battery power when running Linux (note: the TLP acronym has no special meaning). In version 1.9.0 of TLP a profiles daemon similar to GNOME’s power profiles daemon has been added to the project, providing a D-Bus API for controlling some of TLP’s settings.

Our SUSE TLP package maintainer asked us for a review of the changes contained in the new TLP release, leading us to discover issues in the Polkit authentication logic used in TLP’s profiles daemon, which allow a complete authentication bypass. While looking into the daemon we also found some additional security problems in the area of local Denial-of-Service (DoS).

We reported the issues to upstream in December and performed coordinated disclosure. TLP release 1.9.1 contains fixes for the issues described below. This report is based on TLP 1.9.0.

The next section provides a quick overview of the TLP power daemon. Section 3 discusses the security issues we discovered in detail. Section 4 looks into the CVEs we assigned. Section 5 provides a summary of the coordinated disclosure process we followed for these findings.

2) Overview of the TLP Daemon

The new TLP power daemon is implemented in a Python script of moderate size. The daemon runs with full root privileges and accepts D-Bus client connections from arbitrary users. For authorization of clients a Polkit policy defines a couple of actions which are checked in the daemon’s _check_polkit_auth() function. Some of these actions are allowed for local users in an active session without providing further credentials, others require admin credentials.

3) Security Issues

3.1 Polkit Authorization Check can be Bypassed

The check_polkit_auth() function relies on Polkit’s “unix-process” subject in an unsafe way. The function obtains the caller’s PID and passes this information to the Polkit daemon for authorization, which is inherently subject to a race condition: at the time the Polkit daemon looks up the provided PID, the process can already have been replaced by a different one with higher privileges than the D-Bus client actually has.

As a result of this, the Polkit authorization check in the TLP power daemon can be bypassed by local users, allowing them to arbitrarily control the power profile in use as well as the daemon’s log settings.

This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.

Upstream Bugfix

We suggested to upstream to switch to Polkit’s D-Bus “system bus name” subject instead, which is a robust way to authenticate D-Bus clients based on the UNIX domain socket the client uses to connect to the bus. This is what upstream did in commit 08aa9cd.

3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds

The D-Bus methods “HoldProfile” and “ReleaseProfile” can be used by locally logged-in users without admin authentication and allow to establish a “profile hold”, preventing the profile from being automatically switched until it is released again.

The “HoldProfile” method returns a cookie value to the caller which needs to be presented to the “ReleaseProfile” method again to release it. This cookie value is a simple integer which starts counting at zero and is incremented for each call to “HoldProfile”. This makes the cookie value predictable and allows other, unrelated users or applications to release an active profile hold by trying to guess the cookie value in use.

Upstream Bugfix

We suggested to upstream to make the cookie value unpredictable by generating a random number. This is what upstream did in commit a88002e.

3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception

As described in the previous section, the “ReleaseProfile” D-Bus method expects an integer cookie parameter as input. The Python D-Bus framework used to implement the method allows clients to pass non-integer types as cookie, however, which causes an exception to be thrown in the daemon. This does not lead to the daemon exiting, however, since the framework catches the exception.

The issue can be reproduced via the following command line:

user$ dbus-send --system --dest=org.freedesktop.UPower.PowerProfiles \
      --type=method_call --print-reply /org/freedesktop/UPower/PowerProfiles \
      org.freedesktop.UPower.PowerProfiles.ReleaseProfile string:test
Error org.freedesktop.DBus.Python.ValueError: Traceback (most recent call
last):
  File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in
_message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/sbin/tlp-pd", line 223, in ReleaseProfile
    cookie = int(cookie)
ValueError: invalid literal for int() with base 10: dbus.String('test')

Upstream Bugfix

While this is not strictly a security issue, we still suggested to make the daemon more robust by actively catching type mismatch issues for the cookie input parameter. Upstream followed this suggestion and implemented it in the same commit as above which introduces unpredictable cookie values.

3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface

The profile hold mechanism described in section 3.2 allows local users in an active session to create an unlimited number of profile holds without admin authentication. This can lead to resource exhaustion in the TLP power daemon, since an integer is entered into a Python dictionary along with arbitrary strings reason and application_id which are also supplied by the client. This API thus offers Denial-of-Service attack surface.

We found a similar issue in GNOME’s power profile daemon some years ago, but GNOME upstream disagreed with our analysis at the time, which is why SUSE distributions are applying a custom patch to limit the number parallel profile holds.

Upstream Bugfix

We asked upstream whether there are any valid use cases for supporting a large number of profile holds in parallel, and it turns out that the typical use case is only to support a single profile hold at any given time. Thus upstream agreed to restrict the number of profile holds to a maximum of 16, which is implemented in commit 6a637c9.

4) CVE Assignment

We assigned CVE-2025-67859 to track issue 3.1 (Polkit authentication bypass). Issues 3.2 (predictable cookie values) and 3.4 (unlimited number of profile holds) would formally also justify CVE assignments; their severity is low, however, and we agreed with upstream to focus on the main aspect of the Polkit authentication bypass.

5) Coordinated Disclosure

We reached out to the upstream author on December 16 with details about the issues and offered coordinated disclosure. Upstream confirmed the issues and accepted coordinated disclosure. We discussed patches and further details over the course of the following two weeks. Due to the approaching Christmas holiday season we decided to set the general publication date to January 7.

We want to express our thanks to the TLP upstream author for the smooth cooperation in handling these issues.

6) Timeline

7) References

• TLP Website
• TLP GitHub project
• TLP Bugfix Release 1.9.1
• openSUSE Bugzilla review bug for TLP 1.9.1

Table of Contents

• 1) Introduction
• 2) Overview of the D-Bus Service
• 3) Security Issues
  • 3.1) Lack of Client Authorization
  • 3.2 Missing Input Parameter Verification
  • 3.3) Unsafe umask used in Daemonize Code
• 4) Upstream Bugfixes
• 5) CVE Assignment
• 6) Coordinated Disclosure
• 7) Timeline
• 8) References

1) Introduction

Foomuuri is an nftables-based firewall manager for Linux. The project includes a D-Bus daemon which offers an API similar to firewalld. In early December an openSUSE community member asked us to review Foomuuri for addition to openSUSE Tumbleweed.

During the review we quickly noticed a lack of client authorization and input validation in the implementation of Foomuuri’s D-Bus service. We reported the issues to upstream and performed coordinated disclosure. Upstream published version 0.31 of Foomuuri on 2026-01-07 which contains bugfixes for the security issues.

The next section provides an overview of the Foomuuri D-Bus service. Section 3) discusses the security issues in detail. Section 4) provides an overview of the upstream bugfixes to address the issues. Section 5) looks into the CVEs which were assigned. Section 6) gives insight into the coordinated disclosure process which was established for these findings.

This report is based on Foomuuri release v0.29.

2) Overview of the D-Bus Service

Foomuuri runs with full root privileges and registers a D-Bus interface under the name”fi.foobar.Foomuuri1”. Optionally a firewalld drop-in replacement interface is also registered under “org.fedoraproject.FirewallD1”. Both interfaces hook into the same logic, however, and there is no need to look at them separately.

There are only a few methods provided by the D-Bus interface: getting the list of available zones and managing the assignment of network interfaces to zones.

3) Security Issues

3.1) Lack of Client Authorization

There is no authentication layer like Polkit present in the Foomuuri D-Bus service, and there are also no restrictions on D-Bus configuration level as to who is allowed to connect to the D-Bus interfaces provided.

As a result any local user, including low privilege service user accounts or even nobody, can invoke the D-Bus interface and change the firewall configuration. The only state which can be modified this way is the assignment of interfaces to zones, but this is enough to weaken the firewall configuration or to perform a limited Denial-of-Service.

3.2 Missing Input Parameter Verification

Apart from the lack of access restrictions pointed out above, the input parameters to the D-Bus methods are not carefully scrutinized. While the zone input parameter is at least checked against currently configured zones, no further checks are performed on the interface parameter. This means that, e.g. via the “addInterface” D-Bus method, arbitrary strings can be passed as interface name. There is also intentionally no check if the specified name corresponds to an existing network device in the system (to allow seamless coverage of network devices even before they are added to the system).

One result from this can be log spoofing, since the interface name is passed to logging functions unmodified. The string could contain control characters or newlines, which can manipulate the log.

In DbusCommon.add_interface() the possibly crafted interface name is added to the to-be-generated JSON configuration via the out() method. While we did not verify whether this works in practice, a local attacker could attempt to largely control the JSON configuration passed to nftables, by skillfully embedding additional JSON configuration in the interface parameter.

We were worried that this could even lead to arbitrary code execution by abusing features of nftables like loading external files or plugin code, but it turned out that there are no such features available in the nftables configuration format.

3.3) Unsafe umask used in Daemonize Code

Foomuuri contains optional support to daemonize itself. Normally this is done by systemd and the code in question is not invoked. It contains logic to set the daemon’s umask to 0, however, which is a bad default, since applications or libraries which intend to foster user control of the file mode of newly created files can pass modes like 0666 to open(), rendering them world-writable.

Foomuuri does not contain any code paths that create new files, but the umask setting is also inherited by child processes, for example. While we did not think this was a tangible security issue in this form, we suggested to choose a more conservative value here to prevent future issues.

4) Upstream Bugfixes

We suggested the following fixes to upstream:

• restrict access to the D-Bus interfaces to root only, maybe also to members of a dedicated opt-in group. Alternatively Polkit could be used for authentication of callers, which is more effort and complex, however.
• the interface input parameter should be verified right from the beginning of each D-Bus method to make sure that it does not contain any whitespace or special characters and is not longer than IFNAMSIZ bytes (which is currently 16 bytes on Linux).
• as an additional hardening measure we also suggested to apply systemd directives like ProtectSystem=full to Foomuuri’s systemd services, to prevent possible privilege escalation should anything go wrong at the first line of defense.

Upstream decided to implement Polkit authentication for Foomuuri’s D-Bus service and otherwise followed closely our suggestions:

• commit 5944a42 adds Polkit authentication to the D-Bus service. Changing firewall settings now requires admin authorization. The use of Polkit can be disabled in Foomuuri, in which case only clients with UID 0 are allowed to perform the operations.
• commit d1961f4 adds verification of the interface parameter to prevent manipulation of the JSON configuration data.
• commit 806e11d sets the umask used in the daemonize code to a more conservative 0o022 setting, preventing world- or group-writable files from coming into existence.
• commit 5fcf125 adds the ProtectSystem=full directive to all Foomuuri systemd service units.

All of the bugfixes are contained in version 0.31 of Foomuuri.

5) CVE Assignment

In agreement with upstream we assigned the following two CVEs corresponding to this report:

• CVE-2025-67603: lack of client authorization allows arbitrary users to influence the firewall configuration (issue 3.1).

• CVE-2025-67858: a crafted interface input parameter to D-Bus methods can lead to integrity loss of the firewall configuration or further unspecified impact by manipulating the JSON configuration passed to nft (issue 3.2).

6) Coordinated Disclosure

We reported these issues to the upstream developer on 2025-12-11, offering coordinated disclosure. We soon got a reply and discussed the details of the non-disclosure process. Upstream quickly shared patches with us for review and we agreed on the final patches already on 2025-12-19. In light of the approaching Christmas season we agreed on a publication date of 2026-01-07 for general disclosure.

We want to thank the upstream author for the prompt reaction and cooperation in fixing the issues.

7) Timeline

8) References

• Foomuuri GitHub project
• Foomuuri v0.31 Bugfix Release