GRUB2 with BLS is now in MicroOS and Tumbleweed

Recently the openSUSE project released for MicroOS and Tumbleweed a new version of the GRUB2 package, with a new subpackage grub2-$ARCH-efi-bls. This subpackage deliver a new EFI file, grubbls.efi, that can be used as replacement of the traditional grub.efi.

The new PE binary is a version of GRUB2 that includes a set of patches from Fedora, which makes the bootloader follow the Boot Loader Specification (BLS). This will make GRUB2 understand the boot entries from /boot/efi/loader/entries, and dynamically generate the boot menu showed during boot time.

This is really important for full disk encryption (FDE) because this means that now we can re-use all the architecture and tools designed for systemd-boot. For example, installing or updating the bootloader can now be done with sdbootutil install, the suse-module-tools scriptlets will create new BLS entries when a new kernel is installed, and the tukit and snapper plugins will take care of doing the right thing when snapshots are created or removed.

Reusing all those tools without modification was a significant win, but even better, many of the quirks that classical GRUB2 had when extending the event log are no longer present. Before this package, sdbootutil needed to take ownership of the grub.conf file, as this will be measured by GRUB2 by executed lines. That is right! For each line that is read and executed by the GRUB2 parser, a new PCR#8 will take place, and because GRUB2 support conditional as other complex constructors, it is very hard to predict the final value of PCR#8 without imposing a very minimal and strict grub.conf.

However, with the new BLS subpackage, this file, along with the fonts and graphical assets for the theme, and the necessary modules (such as bli.mod), are now included in the internal squashfs within the EFI binary. GRUB2 will no longer measure those internal files without compromising security guarantees because now it is the firmware that measures the entire EFI when the bootloader is executed during the boot process.

As today, we cannot use YaST2 to install GRUB2 with BLS, but we can do that manually very easily. We need to make a systemd-boot installation, replace LOADER_TYPE from systemd-boot to grub2-bls in /etc/sysconfig/bootloader, install the new GRUB2 BLS package, and do sdbootutil install. Another option is to play with one of the available images for MicroOS or Tumbleweed.

Have a lot of fun!

This weekend I visited the first Audio Expo in Budapest. It was the first music event I truly enjoyed in years. Even if corridors and rooms were packed, there was enough fresh air. What sets this event apart from other events is the focus on listening to music on the vendors’ products rather than just the speeds and feeds on why you should buy their products. While, of course, the expected outcome is the same, with the emphasis on listening to live systems, I found the event much more comfortable to walk around.

Key takeaway

Do not judge quickly! Go back to a place multiple times! If you are lucky, there will be less people in the room, and you can sit at a better spot. You can also listen to a different music, or listen to the same speakers with a different amplifier. Actually, both of these happened to me this weekend, and brought drastic changes to the experience.

Best of Audio Expo

Everyone is asking me what I liked the most. I am not an engineer when it comes to listening to music. I just listen to my ears and do not care much about the technical details. At home I listen to a pair of Heed Enigma 5 speakers, which are omnidirectional. At the expo the best listening experience was another omnidirectional speaker: the MBL speakers at Core Audio. This was also probably the most expensive setup at the expo.

According to my ears the best value award should go to NCS Audio Reference One PREMIUM. I visited all rooms on all floors and listened to many different speakers along the way. Some were close to or matching the sound quality of the NCS Audio speakers, however for a lot higher price. I only felt with the MBL speakers that they sounded better, however from the price difference you can buy a luxury car :-)

Exhibitors

I had various programs in the neighborhood, so instead of a long block at the Audio Expo, I spent three times a few hours there. Some places I visited multiple times, just to ensure that my first judgment was not too quick. Let me share here my experiences with some of the exhibitors, in alphabetical order.

Allegro Audio

As usual, the system exhibited at Audio Expo sounded really nice. Allegro Audio not only distributes some quality components, but also has its own amplifier: Flow. I really love listening to their Franco Serblin Accordo monitor speakers, but Ktema was not bad either :-)

Core Audio

Probably the most expensive setup of the expo was exhibited by Core Audio. However, the first time I visited them, they played some terrible (at least to me) music. With that music, the whole setup sounded like a pair of $100 computer speakers. So, I started to wonder what is all the hype about MBL speakers… Fortunately, I returned to the show the next day and with a different selection of music, the system really shined, and became the best sounding system of the whole Expo. However, price is prohibitively expensive for most people…

Heed

I listen to various Heed components at home: DAC, amp and speakers. So, I was very happy to see the founder talking about the latest Heed products, and also having the opportunity to listen to them. I love Heed speakers, especially the omnidirectional variants, however for the demo they used GoldenEar speakers with the Heed amplifiers at the Expo. Not bad at all, but different.

NCS Audio

I already listened to Reference One a few times, and I was amazed. Rock, classical, jazz and others, all sounded perfectly on these speakers, no matter the room size. This time Reference One Premium was on stage, using cables from Bonsai Audio. This pair sounded even better than speakers costing many times more.

Popori Acoustics

I have been reading about Popori Acoustics for years. Finally I had a chance to listen to these electrostatic speakers made in Hungary for the first time. And I must admit that my first listening experience was not that good. Hearing a woman singing was fantastic. However, even if the sound of bass guitar was very detailed, it still sounded a kind of meh. Luckily I went back on the second day of the expo again. The amplifier was replaced, and suddenly not just human voice, but everything sounded perfectly.

Closing words

Of course there were many more exhibitors. In some cases I loved the sound I heard, but did not have enough time to go back, ask questions, take photos. Some examples are 72audio and Sabo Audio. And there were many more, where the sound was not bad, but did not impress me too much either.

I really hope that next year we will have a similarly good Audio Expo in Budapest!

Hello everyone!

I’d like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will currently offer you Base, GNOME, and KDE.

Users can get our new Agama install images from get.opensuse.org/leap/16.0. The installer will currently offer you Base, GNOME, and KDE installation.

Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.

We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they’re used to from previous releases.

Further details are available on our roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.

Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.

There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS.

Who should get it?

This is a pre-alpha product that is not intended to be installed as your daily driver. I highly recommend starting with the installation in a virtual machine and becoming familiar with the online installer Agama.

The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware.

For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025.

How to report bugs?

I’d like to kindly ask you to check our Known bugs wikipage before reporting a new issue. If you find a new issue that is likely to affect users, please feel free to add it to the page.

Specifically for Agama I highly recommend using github.com/agama-project and collaborating with the YaST team on suggestions and incorporating any changes.

For the rest of the components, the workflow isn’t changing; just select version 16.0 for bug submissions.

Feature requests

All changes to packages inherited from SLES 16 need to be requested via a feature request.

Feature requests will be reviewed every Monday at a feature review meeting where we’ll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable.

The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running osc ls SUSE:SLFO:1.1:Build.

Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X. SLFO was previously known as Adaptable Linux Platform (ALP).

I highly recommend using code-o-o to co-ordinate larger community efforts such as Xfce enablement, where will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article.

Where to submit packages, how is it built, and where is it tested?

Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can mirror SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.

For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group. Later, we plan to rework the existing Leap 16.0 Images job group for testing the remaining appliance images.

The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).

Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers poo#164141 Leap 16.0 enablement and poo#166562 upgrade from 15.6.

Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we’d like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.

Involvement in branding and marketing efforts

I’m very proud to announce fresh branding efforts and want to thank all the people who helped give Leap and Tumbleweed a new look. We plan to publish an article or a video about the changes, and further plans as we still have a surprise or two in our pocket.

Do you want to help us on this front? Spread the news and feel free to join the openSUSE Marketing Team in our Telegram channel.

Many thanks to all who helped us to reach this point.

Lubos Kocman
on behalf of the openSUSE Release team

Dear Tumbleweed users and hackers,

We released six snapshots during 2024/40 (0926, 0927, 0929, 0930, 1001, and 1002). Based on personal feelings, the week seemed ‘mixed’ – Requests came in, and requests went out. And a few things seem to hang there for longer again.

Let’s first look at what you have received during the last week, starting on the positive side of things:

• Bash 5.2.37
• cURL 8.10.1
• fwupd 1.9.25
• GStreamer 1.24.8
• GTK 4.16.2
• Linux kernel 6.11.0
• openSSH 9.9p1
• systemd 256.6
• TCL 8.6.15
• PostgreSQL 17.0 (final release)
• LibreOffice 24.8.2.1
• PHP 8.3.12
• Audit 4.0
• timezone 2024b
• Virtualbox 7.1.0
• Cups 2.4.11
• AppArmor 4.0.3
• grub2: introduces a new package, grub2-x86_64-efi-bls, which includes a straightforward grubbls.efi file

On the staging projects, we have some larger changes being worked on by multiple people. Some of the more interesting changes to come are:

• Libproxy 0.5.9
• KDE Plasma 6.2
• GNOME 47: webkit2gtk3 breaks python-wxPython on i586; help appreciated
• Busybox 1.37.0
• XWayland 24.1.3
• LLVM 19
• Mesa 24.2.x: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11840
• Change of the default LSM (opted in at installation) to SELinux. AppArmor is still an option, just not the default. This change only impacts new installations.

Table of Contents

• 1) Introduction
• 2) Vulnerability Details
• 3) Embargo Process and Upstream Communication
• 4) SUSE Bugfix
  • Improved version of the Patch after Discussions in the Community
• 5) Upstream Bugfix
• 6) Timeline
• 7) References
• 8) Change History

1) Introduction

oath-toolkit contains libraries and utilities for managing one-time password (OTP) authentication e.g. as a second factor to password authentication. Fellow SUSE engineer Fabian Vogt approached our Security Team about the project’s PAM module. A couple of years ago, the module gained a feature which allows to place the OTP state file (called usersfile) in the home directory of the to-be-authenticated user. Fabian noticed that the PAM module performs unsafe file operations in users’ home directories. Since PAM stacks typically run as root, this can easily cause security issues.

The feature in question has been introduced in oath-toolkit version 2.6.7 (via commit 60d9902b5c). The following report is based on the most recent oath-toolkit release tag for version 2.6.11.

2) Vulnerability Details

The PAM module is typically configured using a PAM stack configuration line like this:

auth [user_unknown=ignore success=ok] pam_oath.so usersfile=${HOME}/user.oath window=20

The expansion logic of the path components ${HOME} or ${USER} is part of the problematic feature that introduced the security issue.

The PAM module invokes a liboath library function called oath_authenticate_usersfile() found in liboath/usersfile.c, which manages all accesses to the usersfile. Privileges are not dropped, and the function is not aware of the special privileged PAM context. All file accesses in the function are naive and follow symlinks. The relevant file operations that are carried out on successful OTP entry are as follows:

• opening of the usersfile via fopen() for reading (usersfile.c:470).
• opening of a lockfile parallel to the usersfile using a filename suffix “.lock” via fopen() for writing (usersfile.c:332)
• locking of the lockfile using POSIX advisory locks via fcntl() (usersfile.c:350)
• creation of a new usersfile parallel to the old usersfile using a filename suffix “.new” via fopen() (usersfile.c:372)
• changing ownership of the new usersfile to the to-be-authenticated user via fchown() (usersfile.c:394)
• renaming of the new usersfile to the old usersfile via rename() (usersfile.c:411)
• unlinking of the previously created lockfile (usersfile.c:423)

If this happens in a PAM stack running as root and the usersfile is located in an unprivileged user’s home directory, then a simple root exploit is possible by placing a symlink like this:

user$ ln -s /etc/shadow $HOME/user.oath.new

This will cause /etc/shadow to be overwritten and its ownership will be changed to the to-be-authenticated user. The to-be-authenticated user can obtain full root privileges. No race condition needs to be won and no pathnames have to be guessed.

3) Embargo Process and Upstream Communication

Fabian Vogt first approached the main upstream author by email. Since we did not get a reaction for several days, we created a private Gitlab issue in the upstream project, offering coordinated disclosure. There was no reaction, thus we decided to handle the embargo and bugfix ourselves, since we needed a fixed pam_oath module for our products. We developed a comprehensive patch, described in Section 4) below.

We requested a CVE from Mitre for this issue and they assigned CVE-2024-47191.

As we were preparing to go public, the upstream author got pinged via private channels and reacted to our report, preparing an upstream bugfix release addressing the issue, described in Section 5) below.

Due to time constraints, we have decided to apply our SUSE bugfix to our products for the time being, until we can evaluate the upstream solution in more depth.

4) SUSE Bugfix

We developed a patch within SUSE to address the issue (note that there is an improved version of the patch available by now). The situation for the bugfix is more complex than it might look at first, because many things are unclear or broken in the current source code:

• the PAM module cannot know for sure if the target usersfile is supposed to be owned by root or by the to-be-authenticated user, or even some unrelated user. The presence of a ${HOME} path element makes it likely that the to-be-authenticated user is supposed to own the file. The presence of a ${USER} element is not that clear, however.
• the locking mechanism used in the current source code is broken:
  • the usersfile is initially opened for reading and parsed without owning the lock (usersfile.c:470). A parallel task can be about to replace this file with a new version, thus a lost update can occur.
  • the lock file is unlinked again after the usersfile has been updated (usersfile.c:423). This breaks when another task is waiting on the now-unlinked lockfile, while a third task arrives, sees no lockfile and creates a new one.
• the lockfile is placed in the user’s home directory, possibly cluttering it. Cases like the home directory being a network file system (NFS, CIFS) would need to be considered. The unprivileged user might also prevent the privileged PAM stack from obtaining the lock, causing a local denial-of-service.

We decided to develop a patch that takes as many use cases as possible into account, securing all operations while maintaining backwards compatibility. With the patch, the usersfile path is safely traversed using the *at family of system calls. Privileges will be dropped to the owner of the usersfile as an additional security measure. The locking mechanism has been fixed to cover all accesses to the usersfile. Instead of creating a separate lockfile, the usersfile itself is used for locking, which avoids cluttering the home directory. Additional sanity checks are added e.g. world-writable directory components are denied. The patch employs Linux specific features (e.g. linking files from /proc/self/fd), thus it no longer works for non-Linux systems. The patch description and code comments contain more hints about the individual decisions taken in this patch.

Improved version of the Patch after Discussions in the Community

After detailed discussions on the oss-security mailing list a few shortcomings of the original SUSE patch have been identified:

• the patch lacks logic to drop supplemental group membership, which typically results in the process retaining root group membership. Since the privilege drop in the patch only serves as a hardening this is not critical.
• the patch does not deal with potential hard link attacks. Hard link attacks are difficult to protect from, which is why on SUSE distributions the kernel sysctl “sys.fs.protected_hardlinks” is active by default. This way the kernel prevents dangerous uses of hardlinks.

For completeness we offer an improved patch that addresses these two aspects. The approach taken in the patch - to accept any ownership of the target file - makes it impossible to fully protect against all hardlink attack scenarios, though. This is outlined by Solar Designer in the thread on the oss-security mailing list.

5) Upstream Bugfix

Upstream developed an alternative solution, designed to be more portable and cross-platform. This does not take into account all aspects that we considered in Section 4), but should be sufficient to fix the specific security issue described in this report.

This fix has been released in version 2.6.12 of oath-toolkit. Upstream has also published an associated Security Advisory.

6) Timeline

7) References

• oath-toolkit repository
• oath-toolkit vulnerable usersfile commit
• oath-toolkit upstream private issue
• SUSE improved bugfix
• SUSE initial bugfix (old version)
• oath-toolkit Security Advisory for CVE-2024-47191

8) Change History

Two weeks ago, I was at EuroBSDcon and received a feature request for syslog-ng. The user wanted to collect FreeBSD audit logs together with other logs using syslog-ng. Writing a native driver in C is time consuming. However, creating an integration based on the program() source of syslog-ng is not that difficult.

This blog shows you the current state of the FreeBSD audit source, how it works, and its limitations. It is also a request for feedback. Please share your experiences at https://github.com/syslog-ng/syslog-ng/discussions/5150!

Read more at https://www.syslog-ng.com/community/b/blog/posts/freebsd-audit-source-for-syslog-ng

The schedule for this year’s openSUSE.Asia Summit is out and features a diverse lineup of talks highlighting advancements in open-source and with the project.

This year’s event takes place in Tokyo, Japan, and is a two-day event running from Nov. 2 to Nov. 3, that includes talks about technologies involving openSUSE, Fedora, Ubuntu, Debian, AlmaLinux, Rocky Linux, and many other open-source projects.

The summit brings together developers, community members and open-source enthusiasts from around the world to Asia for discussions about Linux distribution updates to security and design.

Fuminobu Takeyama will open the event with a welcome address, which will be followed by a keynote from the company providing the venue, SHIFT Inc.. This will be followed by a talk about What is openSUSE? and talks about the future of Leap and an update about the Geeko Foundation. Trustees from the Geeko Foundation will provide an overview of the foundation’s financial and operational progress as well as providing insights about the use of the Travel Support Program, fundraising efforts and more.

A technical keynote about container and virtualization platforms focusing on openSUSE Leap Micro and a talk about language support for LibreOffice based on specific needs of Chinese, Japanese, and Korean (CJK) users will take place toward the beginning of the summit.

A talk related to secure software packaging and and AI/ML edge computing will provide some great content for attendees on the first day of the summit.

The second day is scheduled to have talks covering areas like the future of desktop Linux, free software in healthcare and geographic information systems using open-source technologies.

Find the schedule at events.opensuse.org.