Table of Contents

• 1) Introduction
• 2) wait3() as a Side Channel in Setuid Programs
• 3) File Existence Test (CVE-2024-0149)
• 4) Bugfix
• 5) CVE Assignment
• 6) Other Packages
• 7) Timeline
• 8) References

1) Introduction

nvidia-modprobe is a setuid-root helper utility for the proprietary Nvidia GPU display driver that loads kernel modules and creates character devices required for userspace GPU access. Normally, drivers do this via udev. However, kernel licensing restrictions prohibit Nvidia’s proprietary kernel module from generating uevents, which are required for udev to work. Therefore this special helper is needed.

We reviewed nvidia-modprobe as part of our whitelisting process, which requires an audit for all newly introduced setuid binaries in openSUSE. The version we reviewed was 550.127.05 and this report is based on that version. Upstream released a bugfix in version 550.144.03 and a security advisory.

2) wait3() as a Side Channel in Setuid Programs

The wait3() system call allows the calling process to obtain status information for child processes, similar to waitpid(). Unlike waitpid(), wait3() also returns resource usage information. The measurements returned by this call include CPU time, memory consumption and lower-level information such as the number of minor and major page faults that occurred during the child’s runtime. See also man 2 getrusage.

Perhaps surprisingly, wait3() also works for setuid sub-processes, leaking quite a bit of information about the behavior of the target program, which is running with elevated privileges.

A convenient way to try this out is GNU Time, a small utility that spawns a target process and prints the output of wait3(), for example:

/usr/bin/time -v nvidia-modprobe

3) File Existence Test (CVE-2024-0149)

In the case of nvidia-modprobe, we can leverage wait3() for a file existence test.

When executed with the option -f NVIDIA-CAPABILITY-DEVICE-FILE (an arbitrary path), nvidia-modprobe performs the following steps:

• attempt to open the supplied path as root
  • if the path does exist:
    • read one or more lines
    • parse each line (implemented safely)
    • exit silently, return code 0
  • if the path does not exist:
    • exit silently, return code 0

It turns out that reading the first line of the supplied path sometimes causes a minor page fault. The number of page faults is not perfectly constant across multiple executions, depending on whether the page mapped by the kernel is dirty or not. However, if the file does not exist, it cannot be read, and therefore no page faults will be triggered. We can execute nvidia-modprobe repeatedly, calculate the median number of page faults, and infer whether the supplied path exists or not, even if the caller does not have the necessary file system permissions.

Simplified example:

$ /usr/bin/time -q --format=%R nvidia-modprobe -f /root/.bash_history
80

$ /usr/bin/time -q --format=%R nvidia-modprobe -f /root/does/not/exist
79

The output fluctuates, but it only takes a few repetitions to get a reliable signal from the median.

4) Bugfix

Upstream published a bugfix. This commit limits the queried path to files below /proc/driver/nvidia before attempting to read from it, eliminating the information leak.

5) CVE Assignment

Upstream assigned CVE-2024-0149 for this issue.

6) Other Packages

Considering the relatively obscure nature of this side channel attack, we decided to briefly look into a couple of other packages exhibiting similar usage patterns:

• shadow
  • chsh: negative
• util-linux
  • mount -T: negative
  • umount: negative
• v4l-linux: positive, but does not require wait3(), and the issue was already known (CVE-2020-1369).

Even though we did not find additional instances of this problem, and the severity of this vulnerability is rather low, it’s still one of many pitfalls to keep in mind when writing or auditing setuid programs.

7) Timeline

8) References

• nvidia-modprobe GitHub repository
• Nvidia security advisory
• Bugfix commit 83b777c
• getrusage(2)

Table of Contents

• 1) Introduction
• 2) Synce4l Synchronous Ethernet Daemon
• 3) Fwupd 2.0 D-Bus and Polkit Changes
• 4) Tuned Revisited
• 5) iio-sensor-proxy Revisited
• 6) systemd-sysupdated D-Bus Service
• 7) AppArmor aa-notify Polkit Policy
• 8) Conclusion
• 9) References

1) Introduction

Winter time is coming to an end (at least in the northern hemisphere, where most of the SUSE security team members are located), and with this we want to take a look back at what happened during the last three months in our team. We have already posted about a number of bigger topics that kept us busy over the winter:

• privilege separation issues in SSSD
• problematic return values in pam-u2f
• authentication bypass in dde-api-proxy
• authentication bypass in pam_pkcs11
• admittance of kio-admin into openSUSE
• problematic log directory permissions in Below
• file existence test in nvidia-modprobe

As usual in the spotlight series, in this post we want to give an insight into some of our work beyond these reports: reviews that did not lead to significant security findings, but still kept us busy and in some cases also led to upstream improvements. The topics again mostly involve Polkit authentication and D-Bus APIs, but we also looked proactively into a piece of networking software that raised our interest.

2) Synce4l Synchronous Ethernet Daemon

Our team is monitoring changes and additions to openSUSE Tumbleweed, most notably systemd services that newly appear in packages. The synce4l package raised our interest, because it contains a daemon which is running with full root privileges and is also networked. The package implements synchronous Ethernet, a low level protocol that basically maintains a shared clock between multiple hosts in an Ethernet subnet.

The project is implemented in the C programming language and consists of about 7.000 lines of code. The sensitivity of C programs to memory handling issues, the fact that the synce4l daemon runs as root and the niche topic of synchronous Ethernet is a mixture that makes it an interesting code review target.

We reviewed the source code in early January and fortunately couldn’t find any issues in it. The attack surface on the network is rather small. Even though by default there is no trust established between participants of the protocol, there is only an integer value exchanged between nodes. Corruption of this value cannot negatively influence a system running synce4l (beyond the protocol itself, naturally). The daemon also creates a UNIX domain socket in /tmp, but access to it is limited to root. The project employs a good coding style and we did not have any concerns left when we were finished with the review.

3) Fwupd 2.0 D-Bus and Polkit Changes

In January the openSUSE maintainer for fwupd packaged the major version 2.0 update, which required a follow-up audit by our team. fwupd is part of most Linux distributions and provides mechanisms to automatically upgrade firmware on the system. The fwupd daemon runs as root and implements a D-Bus interface with Polkit authentication. We have already reviewed it many times when changes to these interfaces have occurred.

Even though this time fwupd has received a major version update, there have only been moderate changes to the D-Bus and Polkit aspects of the software. Generally, the implementation of the D-Bus interface in fwupd is more on the complex side. Polkit authentication is implemented properly, but it is only applied to a subset of the D-Bus methods offered by the daemon. This means that one has to carefully differentiate between the methods that require Polkit authentication, and the ones that don’t require any authentication at all. This is what we did during the review; fortunately we couldn’t find any problems with the unauthenticated methods.

One notable feature that has been added in this fwupd release allows it to run its own dedicated D-Bus instance, likely for lean and mean environments or for use in early boot scenarios, when no system D-Bus is available. When this feature is in use then no Polkit authentication will be performed, likely because no Polkit daemon is present either in this situation. This mode will only be active when the environment variable FWUPD_DBUS_SOCKET is passed to the daemon, however, and should not be reachable in regular installations of fwupd.

There was one new Polkit action org.freedesktop.fwupd.emulation-load, which was allowed for users in a local session without authentication. The corresponding D-Bus method accepts JSON data, either directly or placed in a compressed archive which is passed to the daemon. This is used to load “hardware emulation data” into fwupd. This sounded like a strong privilege for a regular user to have, and thus we inquired upstream if this lax authentication setting was actually necessary. The outcome was that we could raise the authentication requirement to auth_admin, thereby improving security in fwupd.

4) Tuned Revisited

tuned has seen quite a number of changes recently, which also led to a local root exploit finding in November. We received yet another review request in January due to further changes in the area of D-Bus configuration and Polkit actions.

Security-wise there was not much interesting to find in these changes. A number of Polkit actions have been renamed, and tuned optionally provides a drop-in replacement for the UPower D-Bus interface now. We accepted the changes without further ado.

5) iio-sensor-proxy Revisited

iio-sensor-proxy is another package that we already reviewed in the past but that popped up again in January due to changes in its D-Bus configuration. The package provides a D-Bus interface for different hardware sensors like ambient light sensor, accelerometer or proximity sensor. During the review we found that a newly added net.hadess.SensorProxy.Compass.ClaimCompass D-Bus method was unauthenticated, while other similar methods required Polkit authentication.

We reported the issue privately to upstream. The lack of authentication was confirmed and upstream fixed the issue. We did not request a CVE or publish a dedicated report about this, because the impact of the issue is assumed to be low. Such smaller findings still show the usefulness of code reviews that can lead to improvements in upstream code and configuration before software is shipped to openSUSE users.

6) systemd-sysupdated D-Bus Service

In February we received a request to review an experimental systemd component called sysupdated. When reading the program description one could be inclined to think that systemd is now on a quest to replace package managers. The main purpose of this daemon is only to keep container assets and other images up-to-date, however.

sysupdated comes with a larger D-Bus interface protected - in parts - by Polkit. Some read-only properties and method calls are available without Polkit authentication. Systemd components rely on shared code to implement D-Bus services and Polkit authentication. Compared to the last time we had a look into these shared routines, it felt as if the complexity increased quite a lot in this area. You can have a look at this Bugzilla comment to get an impression of the complexities that are involved there these days. One reason for the increased complexity could be the addition of the Varlink IPC mechanism, which can also use Polkit for authentication.

Despite the perceived complexity in the D-Bus and Polkit handling, we couldn’t find any problematic aspects in the implementation. There was one decision to be made about the Polkit action org.freedesktop.sysupdate1.update. The authentication requirements for it are by default set to auth_admin:auth_admin:yes, meaning that users in a local session can update assets managed by sysupdated without authentication. This is also documented in the upstream Polkit policy. This only allows to update assets to the most recent version, not to any specific version nor to downgrade the version. It also doesn’t allow to install any new assets. For this reason we allow updates without authentication in our Polkit easy profile while the other profiles have been hardened to require admin authentication.

7) AppArmor aa-notify Polkit Policy

In February a request arrived to whitelist Polkit actions used by the aa-notify helper which has been added to the AppArmor package. This utility is a graphical program similar to setroubleshoot for SELinux, and allows to identify AppArmor violations and modify the AppArmor profile to allow actions that have been denied.

The two Polkit actions that needed reviewing allow to execute a Python script found in
/usr/lib/python3.11/site-packages/apparmor/update_profile.py via pkexec using a specific command line parameter. This script performs the task of actually modifying the AppArmor profile according to the provided input files. Due to the nature of the script there is no way to execute it safely without admin authentication. This is reflected in the Polkit action settings, which always require auth_admin authorization.

The implementation of the script is a bit peculiar in some ways, and some parts also seem incomplete. The one aspect that was important to check here was that the script must not act in dangerous ways on the file system, e.g. by using unsafe temporary files or by writing to locations that are under control of unprivileged users. We could not find issues of this kind at the time we reviewed it.

As the script can only be invoked with admin credentials and since there is no legit use case to lower this authentication requirement, we did not dig a lot deeper here and accepted the new Polkit policy. We want to keep an eye on this script, however, since it has some potential to be changed in ways that could harm the local system security.

8) Conclusion

Once more, we hope that with this post we have been able to give you some additional insights into our daily review work for openSUSE and SUSE products. Feel free to reach out to us if you have any questions about the content discussed in this article. We expect the spring issue of the spotlight series to be available in about three months from now.

9) References

• synce4l review bug
• fwupd 2.0 review bug
• tuned review bug
• iio-sensor-proxy review bug
• systemd-sysupdated review bug
• AppArmor aa-notify review bug

Recently we enabled nightly syslog-ng builds and container builds for arm64. It means that from now on, you can run the latest syslog-ng on 64bit ARM platforms. For this test, I used a Raspberry Pi 3 running the latest Raspberry Pi OS. As I use Podman everywhere else (I am an openSUSE / Fedora guy), I also installed it here for container management.

Read more at https://www.syslog-ng.com/community/b/blog/posts/nightly-arm64-syslog-ng-container-builds-are-now-available

Dear Tumbleweed users and hackers,

We did it! We reached the ‘week of the Linux desktop’! Maybe not every desktop out there is updated to the latest release yet, but at least we have seen the two major Desktop Environments updated in the last two weeks. That’s just some of the few things that have happened over the last two weeks, which resulted in 12 published snapshots (0306, 0307, 0308, 0310, 0311, 0313, 0314, 0315, 0316, 0317, 0318, and 0319).

the most relevant changes included in these snapshots were:

• Emacs 30.1
• Mozilla Firefox 136.0 & 136.0.1
• GNOME 48.0
• KDE Gear 24.12.3
• KDE Plasma 6.3.3
• KDE Frameworks 6.12.0
• Samba 4.21.4
• Mesa 25.0.1
• Perl 5.40.1
• RPM 4.20.1
• Linux kernel 6.13.6
• Apache 2.4.63
• SELinux 3.8.1
• GStreamer 1.26.0
• systemd 257.4
• git 2.49.0
• gimp 3.0.0 final release
• Python 3.13 has become the primary interpreter. /usr/bin/python3.13 refers to this now.
• GCC 15: GCC 15 provides the libraries (e.g., libgcc_s1, libstdc++), while GCC 14 is still the used compiler.

With such an immense list, it’s surprising there is still work left to be done – but everybody is really active and it’s a pleasure to see things fly through the staging areas. Things currently being worked on include:

• Shadow 4.17.4
• Texlive 2025
• LLVM 20
• Mesa 25.0.2
• pcre is scheduled for removal (please help move everything to pcre2)
• GCC 15 as default compiler (See Staging:Gcc7)

29th – 31st August 2025

About openSUSE.Asia Summit

We are excited to announce that the openSUSE.Asia Summit 2025 will be held in Faridabad, India. This annual event brings together passionate users, developers, and contributors from across the open-source community, particularly openSUSE and FLOSS enthusiasts.

Previous summits have been widely attended by participants from India, China, Indonesia, Taiwan, Japan, South Korea, and more.

Since its inception in Beijing (2014), the openSUSE.Asia Summit has served as a hub for open-source contributors to meet, share knowledge, and engage in discussions about openSUSE and other technologies running on it.

After a few years of virtual events due to the pandemic, we’re excited to once again meet in person and foster communication in a dynamic, collaborative environment.

This year’s summit will focus on:

• Knowledge exchange
• Hands-on workshops
• Creating valuable connections

📢 Note: We will not accept virtual talks this year – only in-person presentations.

📅 The Summit Dates

Mark your calendars! The openSUSE.Asia Summit 2025 will take place from 29th to 31st August 2025, at a premier location in Faridabad, India.

🎉 We also have an exciting excursion for speakers planned on 31st August 2025. More details to be shared soon.

Additionally, consider attending:

• Open Source Summit India
• Open Compliance Summit

Both events are hosted by The Linux Foundation and will take place nearby before our summit.

📍 Venue: MRIIRS, Faridabad, India

We are proud to host the openSUSE.Asia Summit 2025 at: Manav Rachna International Institute of Research and Studies (MRIIRS), located in Faridabad, Haryana, India.

🏛️ About the Venue

• Location: Sector 43, Faridabad, Haryana, India
• Accessibility: Easily accessible by public transport and close to major hubs in the Delhi-NCR region
• Nearby City: Just a short distance from New Delhi, making it easy for attendees to travel

📌 Stay tuned for more details on:

• Exact session halls
• Accommodation options near the venue

🌍 Why Faridabad?

Faridabad, a major city in NCR (National Capital Region), is a rapidly growing tech hub with a vibrant educational ecosystem.

✈️ Reasons to Attend in Faridabad:

• Strategic Location: Easy access from Delhi Airport (IGI) and well-connected public transport
• Thriving Tech Ecosystem: A growing IT and tech industry, making Faridabad an ideal summit location
• Cultural & Culinary Experience: Enjoy the rich history, culture, and cuisine of Delhi-NCR

📌 Explore More:

• Incredible India
• Delhi Tourism

🏰 Explore Delhi While You’re in India!

While you’re attending the openSUSE.Asia Summit 2025, take some time to explore:

✨ Historical Landmarks:

• Red Fort
• Qutub Minar

• India Gate

  

</p>

🍽️ Indian Cuisine:

• Butter Chicken
• Samosas
• Chai!

📌 Plan Your Travel:

• Travel India

🎤 Call for Speakers

📢 We are officially opening the Call for Speakers in June 2025!

We invite open-source enthusiasts, developers, and thought leaders to share their insights at the summit. More information on the submission process will be available soon.

🎯 Interested in speaking? Check our openSUSE events page for updates: openSUSE Events Page

A few weeks ago, a customer walked into a Best Buy, which is a well-known retailer in North America that sells computers, appliances and gadgets of all kinds.

On a mission to buy a new laptop for a family member, the customer sought something simple, reliable and future-proof. After browsing through the selection, a solid Lenovo laptop stood out; it had good hardware, decent battery life and no unnecessary gimmicks.

As the customer approached the checkout and began paying for the new laptop, the salesperson turned and asked an unexpected question:

“Would you like to prepay for Windows?”

The customer blinked in surprise.

“These computers you are displaying don’t include Windows?”

“No,” the salesperson responded. “Windows comes with a 30-day trial offer.”

Without hesitation, the customer responded firmly:

“Absolutely not. I’m putting Linux on it.”

The salesperson hesitated, as if hearing this statement for the first time.

What many people don’t realize is that in certain regions, antitrust laws require manufacturers to sell computers with an option not to preinstall Windows. This is a response to decades of monopolistic practices, where users were forced to pay for a Microsoft license whether they wanted it or not. Some manufacturers have introduced Linux-preinstalled models or “no OS” options, though these remain relatively niche. In regions without such regulations, like the U.S., Windows-free computers are still uncommon outside of specialized retailers and business contracts.

Some stores (depending on the country) are legally required to offer a refund for the cost of the Windows license if the customer chooses not to use it. This is, however, rarely advertised. Many people don’t even know they have a choice or that there is a choice for freedom.

For a new laptop, install a Linux distribution like openSUSE’s Leap, Slowroll, Tumbleweed, Kalpa, Aeon or others.

What You Can Do

If you’re in the market for a new computer, don’t let the assumption of Windows dictate your purchase. Here’s how you can take control of your computing experience:

• Ask for a non-Windows option: Many stores don’t advertise it, but some models are available without a preinstalled OS.
• Request a Windows refund: If your country has consumer protection laws, you might be entitled to a refund for the Windows license if you don’t use it.
• Download and install openSUSE: Head to get.opensuse.org and choose the version that best fits your needs. Leap for long-term stability or Tumbleweed for the latest rolling updates.
• Enjoy a system without restrictions: No licensing fees, no activation headaches, and no locked-down software.

Linux has always been there, unlocked and ready to go.

So the next time you walk into a store looking for a new computer, remember; you have a choice. And that choice can be freedom.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.

SUSE, the main sponsor of the openSUSE Project, is offering a discount on its eLearning platform for members looking to enhance their skills in SUSE technologies.

The eLearning offers a variety of training courses that could be useful to openSUSE users, including Linux administration, Kubernetes, security and systems management.

A couple members from the community reached out to Tori Easterly inquiring about the possibility for members to receive a discount or a more accessible pricing option for those interested in enhancing their skills. As a result, SUSE extended a 20 percent discount.

Enterprise-level training allows people to learn at their own pace and convenience. The courses cover Linux fundamentals, automation and cutting-edge technologies like Kubernetes and container management. The eLearning provides unlimited access to all SUSE IT courses, spanning Linux, Systems Management, Security, Edge Computing and more. As IT evolves rapidly, the curriculum is frequently updated to reflect the latest advancements in SUSE technologies.

openSUSE Project members can get 20 percent off SUSE eLearning courses using the Coupon Code TRAIN2025 upon checkout.

For many years, the development of syslog-ng happened on the master branch in Git. However, if you follow that branch, you might have noticed that there has not been much activity on it lately. That is because we introduced a new branch in git called “develop”.

https://www.syslog-ng.com/community/b/blog/posts/introducing-the-develop-branch-of-the-syslog-ng-git-repo

The March syslog-ng newsletter is now on-line:

• Test syslog-ng on EPEL 10!

• Collecting Active Roles logs centrally using the syslog-ng Windows Agent

• syslog-ng OSE 4.8.1 is now in EPEL 10, quick fix for Elasticsearch

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2025-03-epel-10-elasticsearch-active-roles

Table of Contents

• 1) Introduction
• 2) Symlink Attack in /var/log/below/error_root.log
• 3) Further Issues
• 4) Bugfix
• 5) CVE Assignment
• 6) Hardening Suggestions
• 7) Timeline
• 8) References

1) Introduction

Below is a tool for recording and displaying system data like hardware utilization and cgroup information on Linux. In January 2025, Below was packaged and submitted to openSUSE Tumbleweed. Below runs as a systemd service with root privileges. The SUSE security team monitors additions and changes to systemd service unit files in openSUSE Tumbleweed, and through this we noticed problematic log directory permissions applied in Below’s code.

The version we reviewed in this context was v0.8.1 and this report is based on that version.

Upstream released a bugfix in version v0.9.0 and a security advisory on GitHub.

2) Symlink Attack in /var/log/below/error_root.log

Below’s systemd service runs with full root privileges. It attempts to create a world-writable directory in /var/log/below. Even if the directory already exists, the Rust code ensures that it receives mode 0777 permissions:

    if perm.mode() & 0o777 != 0o777 {
        perm.set_mode(0o777);
        match dir.set_permissions(perm) {
            Ok(()) => {}
            Err(e) => {
                bail!(
                    "Failed to set permissions on {}: {}",
                    path.to_string_lossy(),
                    e
                );
            }
        }
    }

This logic leads to different outcomes depending on the packaging on Linux distributions:

• in openSUSE Tumbleweed the directory was packaged with 01755 permissions (below.spec line 73), thus causing the set_permissions() call to run, resulting in a directory with mode 0777 during runtime.
• in Gentoo Linux the directory is created with mode 01755 resulting in the same outcome as on openSUSE Tumbleweed (below.ebuild). Where the 01755 mode is exactly coming from is not fully clear, maybe the cargo build process assigns these permissions during installation.
• in Fedora Linux the directory is packaged with 01777 permissions, thus the set_permissions() code will not run, because the if condition masks out the sticky bit. The directory stays at mode 01777 (rust-below.spec).
• the Arch Linux AUR package (maybe wrongly) does not pre-create the log directory. Thus the set_permissions() code will run and create the directory with mode 0777.

Below creates a log file in /var/log/below/error_root.log and assigns mode 0666 to it. This (somewhat confusingly) happens via a log_dir variable, which has been changed to point to the error_root.log file. The 0666 permission assignment to the logfile happens in logging::setup(), also accompanied by a somewhat strange comment in the code.

A local unprivileged attacker can stage a symlink attack in this location and cause an arbitrary file in the system to obtain 0666 permissions, likely leading to a full local root exploit, if done right, e.g. by pointing the symlink to /etc/shadow. Even if the file already exists it can be removed and replaced by a symlink, because of the world-writable directory permissions. The attack is thus not limited to scenarios in which the file has not yet been created by Below.

We believe the actual intention of this code might have been to assign mode 01777 (i.e. carrying a sticky bit). The sticky bit is neither contained in the if condition nor in the set_permissions() call, though. With the sticky bit set the Linux kernel’s protected_symlinks logic, which is enabled on most Linux distributions, would protect from symlink attacks.

3) Further Issues

Even on Fedora Linux, where /var/log/below has “safe” 01777 permissions, there is a time window during which problems can arise. As long as below.service has not been started, another local user can pre-create /var/log/below/error_root.log and e.g. place a FIFO special file there. This will pose a local DoS against the below service, since it will fail to open the path and thus fail to start.

If /var/log/below were to be deleted for any reason, then Below would still recreate it using the bad 0777 mode permissions, which can also happen on distributions that initially package /var/log/below using permissions that do not trigger the set_permissions() call in Below’s code.

Below applies many world-writable and world-readable permissions under /var/log/below. This seems a strange choice. For some reason the internal state data of Below is also stored within the log directory in /var/log/below/store. The data is fully world-readable, which could result in information leaks, if Below stores system information there that would not otherwise be accessible to unprivileged local users. We did not check if this applies, though. By pre-creating this directory before below.service runs for the first time, an unprivileged user can control all of its contents, possibly violating the integrity of Below in various ways.

The world-writable logfile error_root.log makes no sense to us as well. Why should arbitrary users in the system be able to modify the log data of Below? This allows log spoofing by local users. Even making the logfile world-readable is considered bad style by some people these days. Why /var/log/below should be world-writable in the first place is also unclear to us. Ideally only root or a dedicated below service user should be allowed to write there.

4) Bugfix

Upstream published a bugfix in commit 10e73a21d67 which is part of Below v0.9.0. The commit basically removes all problematic permission assignments from the code, stating that these directories are better setup by systemd. This seems to refer to an added systemd directive LogsDirectory=below in the below.service file.

With this change no world-writable directories or files should turn up in /var/log/below anymore, and the most severe issues from this report are addressed. The possible matter of world-readable log and store files remains, though.

We did not get any details from upstream about the design decisions in Below that led to this issue or about any further changes that upstream intends to perform to improve security in this area.

5) CVE Assignment

Upstream assigned CVE-2025-27591 for this issue.

6) Hardening Suggestions

It could be considered to apply hardening directives in Below’s systemd service unit that prevent some attack types. Most prominently, restricting write access for the daemon to a range of well known locations comes to mind.

7) Timeline

8) References

• Below GitHub repository
• Below v0.9.0 bugfix release
• Bugfix commit 10e73a21d67
• Below GitHub Security Advisory