Table of Contents

• 1) Introduction
• 2) Issues in krb5_child Helper
  • Upstream Fix
• 3) Issues in sssd_pam Helper
  • Upstream Fix
• 4) Notes on the selinux_child Helper
• 5) Notes on the ldap_child Helper
• 6) Issues in the sssd.service Unit
  • Upstream Fix
• 7) Further Observations
  • 7.a) Environment Variables
  • 7.b) Dumpable Process Attribute Setting
  • 7.c) Debugging Settings
• 8) Suggested Fixes
• 9) Situation on Other Distributions
• 10) Timeline
• 11) References

1) Introduction

SSSD (System Security Services Daemon) is a suite of daemons dealing with user authentication based on mechanisms like LDAP, Kerberos and FreeIPA. This report is based on SSSD release 2.10.0.

SSSD supports setting up user privilege separation by specifying the build time configure switch --with-sssd-user=.... The default in many Linux distributions is still to run SSSD as root, though. When privilege separation is enabled, then file based capabilities are assigned to a couple of helper binaries shipped by SSSD:

/usr/libexec/sssd/sssd_pam      root:sssd 0750 cap_dac_read_search=p
/usr/libexec/sssd/selinux_child root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep
/usr/libexec/sssd/krb5_child    root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep
/usr/libexec/sssd/ldap_child    root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep

Only members of the group of the dedicated sssd account are allowed to execute these privileged helpers. In SSSD before version 2.10.0 these helpers (with the exception of sssd_pam) had setuid-root bits. With commit 7239dd6791 this has been changed to using capabilities instead.

Our openSUSE SSSD packagers enabled privilege separation for the first time in conjunction with the update to version 2.10.0. This caused the privileged helpers to pop up on our radar, and we reviewed them. We found that these helper binaries do not currently provide proper privilege separation in SSSD. Some of them offer attack vectors to escalate to root again, or obtain powerful capabilities. Also the systemd service unit of SSSD has issues when privilege separation is active. The privileged helpers are not world-accessible, so no immediate exploitation by local users beyond the dedicated sssd account is possible.

We privately reported the findings described below to the Red Hat Security team on Nov 15. A coordinated disclosure process was in place for about a month, until the SSSD developers decided that the issues are not security issues, based on the following reasons:

• the issues are not directly exploitable, but only affect defense-in-depth.
• the sssd user and group are powerful by design, since these daemons influence the outcome of authentication.
• privilege separation has been introduced as additional hardening, not as a strong security layer.
• privilege separation was also introduced for some cosmetic purposes: “to allow running SSSD in restricted environment that do not support/allow running apps under uid=0/in user-ns (like restricted OCP profiles)”.

In our opinion, these issues are still security relevant. Consider for example a scenario where a system administrator or packager would allow execution of the privileged binaries to all users in the system, either by accident or by a false expectation of security. While it is common practice to deny world access to privileged binaries, in our experience this is usually done as a hardening measure only, not to protect against known weaknesses in programs. While the permissions of the helpers are correctly applied in SSSD’s installation routine, there is no documentation found that these helpers are security sensitive and must not be accessible to accounts other than sssd.

We did not press for CVE assignments, although we believe that formally they would still be justified. We recognize that it can still be an improvement to run SSSD processes as non-root, even if the privileged helpers allow escalation back to root.

Upstream has nonetheless worked and still works on a range of fixes to address findings from this report. The individual issues we identified are discussed in the following sections.

2) Issues in krb5_child Helper

Like most of the other helpers, this program accepts binary input on STDIN. The krb5_child helper reads the large and complex data structures struct krb5_req and struct pam_data. Interesting struct fields in this context are krb5_req.ccname and krb5_req.keytab, which specify file paths to process.

The ccname field is used in the code path privileged_krb5_setup() → k5c_ccache_setup() → k5c_precreate_ccache(). This ends up in a loop that creates all the parent directories of the path specified via STDIN, using uid and gid values also received from STDIN.

This proof-of-concept shows how to create arbitrary new directories with arbitrary ownership this way. This very likely allows a full local root exploit by skillfully creating directories under attacker control, e.g. directories used during lookup for trusted system binaries or libraries, or directories in /etc that are used for trusted configuration files or privileged services.

Upstream Fix

This specific escalation path has been addressed in the SSSD 2.10.1 bugfix release. Given the extensive interface offered by this helper program it is likely that further such escalation vectors exist. Since upstream does not consider this a strong security barrier, we have not looked any deeper into this component.

3) Issues in sssd_pam Helper

This helper starts a server instance which offers a socket-based IPC interface for passing PAM operation requests to it. This is the only helper that has more limited capabilities, namely only CAP_DAC_READ_SEARCH, which allows to override any read-access permission checks.

In the code path server_setup() → confdb_init() the following environment variables are interpreted in ldb_init() (which is part of Samba library code):

• LDB_MODULES_PATH
• LDB_MODULES_ENABLE_DEEPBIND
• TDB_NO_FSYNC

The LDB_MODULES_PATH variable allows the caller to specify a directory from which arbitrary shared objects are loaded via dlopen(). This simple proof-of-concept shows how to exploit this situation to gain access to the contents of /etc/shadow.

Contrary to the other helper programs, sssd_pam was not assigned setuid-root bits previously. The CAP_DAC_READ_SEARCH has only more recently been added via commit 0562646cc261, to allow it to access keytabs without having to run as root.

Upstream Fix

There is a pending upstream pull request to clear the environment of this helper to prevent this specific privilege escalation path.

4) Notes on the selinux_child Helper

We haven’t found any specific privilege escalation paths in this helper. The nature of this helper is to allow modification of SELinux MLS mappings, though. It accepts the new MLS range for arbitrary usernames via a binary protocol on STDIN. In an SELinux MLS managed system this is a pretty strong privilege for SSSD to have. Since this is likely by design, we suppose there is little that can be done about that, except for documenting the sensitive nature of the helper and that access to it must be well restricted.

The helper performs calls into shared SSSD library code and into libsemanage and libselinux. Luckily we couldn’t find any cases where overly problematic environment variables are interpreted (beyond the common variables listed in section 7.a).

This helper also changes its UID and GID to 0 early on. When transitioning to UID 0, the kernel does not assign the full set of capabilities to the process again. This means that the process runs under restricted root privileges, having UID and GID 0 but only the capabilities assigned to the selinux_child binary. Additionally, the SSSD processes run with the systemd hardening feature SecureBits=noroot noroot-locked, thus preventing the helper from using setuid binaries like sudo to regain full root privileges.

The security of restricted root privileges in Linux is lacking, though. The Linux kernel uses capabilities for its permission checks, but userspace utilities normally only rely on other process’s UID and GID credentials. Also some APIs lack the possibility to express restricted root privileges, e.g. in UNIX domain sockets the SO_PEERCRED option is used to determine the credentials of a peer process, which only provides a struct ucred, containing the peer process’s PID, UID and GID. Thus this helper runs with privileges close to full root.

5) Notes on the ldap_child Helper

We couldn’t find any bigger problems in this helper, beyond the generic comments in section 7) that also apply to this helper.

6) Issues in the sssd.service Unit

The sssd.service systemd unit contains the following ExecStartPre lines:

ExecStartPre=+-/bin/chown -f -R root:@SSSD_USER@ @sssdconfdir@
ExecStartPre=+-/bin/chmod -f -R g+r @sssdconfdir@
ExecStartPre=+-/bin/sh -c "/bin/chown -f @SSSD_USER@:@SSSD_USER@ @dbpath@/*.ldb"
ExecStartPre=+-/bin/chown -f -R @SSSD_USER@:@SSSD_USER@ @gpocachepath@
ExecStartPre=+-/bin/sh -c "/bin/chown -f @SSSD_USER@:@SSSD_USER@ @logpath@/*.log"

The directories /var/log/sssd and /var/lib/sssd are owned by the unprivileged sssd user. The chown and chmod lines above, which are run as root, allow a compromised sssd user to stage symlink attacks and thus gain ownership of, or access to, privileged system files.

This is a simple proof-of-concept demonstrating the issue:

# stage a symlink attack to gain ownership of /etc/shadow
sssd$ cd /var/log/sssd
sssd$ ln -s /etc/shadow my.log
# as root trigger a sssd (re)start
# sssd needs to be configured (i.e. /etc/sssd & friends need to exist) for this to work
root# systemctl restart sssd.service
root# ls -lh /etc/shadow
-rw------- 1 sssd sssd 889 Nov 13 11:40 /etc/shadow

As the directories that are affected by this are not world-writable and don’t carry a sticky bit, the Linux kernel’s symlink protection does not come to the rescue here. Path arguments that are named directly on the command line of chown or chmod will be followed, if they’re symlinks, unless --no-dereference is passed. Passing this option is also the recommended fix for this.

In our opinion such automatic permission “fixes” should be treated with care. If this is to avoid any trouble with migration from older installations (without privilege separation) then we would rather offer an explicit utility for system administrators to run. This would make clear that the logic only runs once and not every time sssd is started. It also would prevent any configuration errors from persisting or from being masked (e.g. other components in the system that assign bad permissions to SSSD files, thus fighting against the automatic permission fixes).

Upstream Fix

There is a pending upstream pull request to pass --no-dreference to the chown invocations found in the systemd service unit.

7) Further Observations

7.a) Environment Variables

There are further environment variables interpreted by the helper programs:

• TALLOC_FREE_FILL: will cause memory free()‘d via talloc_free() to be overwritten with the byte set in this variable.
• _SSS_DOM: will influence systemd journal log messages and thus allow a bit of log spoofing.

While these variables have only minor influence on program execution, privileged programs should not allow arbitrary environment settings to affect their behaviour.

7.b) Dumpable Process Attribute Setting

All of the privileged helpers support a --dumpable command line switch to control whether the process will have the dumpable bit set or not. The default for this even is to mark the process as dumpable (SUID_DUMP_USER). This somewhat unexpectedly overrides the sysctl setting fs.suid_dumpable, which is usually 0 or 2.

The dumpable setting of a process is a sensitive property that plays an important role in the ptrace() system call to determine whether tracing another process is allowed. From man 2 ptrace:

These checks are performed in cases where one process can inspect sensitive information about, or in some cases modify the state of, another process. The checks are based on factors such as the credentials and capabilities of the two processes, whether or not the “target” process is dumpable […]

We believe the only barrier left that prevents the unprivileged sssd user from being allowed to trace the privileged binaries is this (further excerpt from man 2 ptrace):

(5.2) Deny access if neither of the following is true: - The caller and the target process are in the same user namespace, and the caller’s capabilities are a superset of the target process’s permitted capabilities.

Attaching via ptrace() is only denied because the target processes have raised capabilities. However, this is only a kind of kernel security extension, provided by the kernel security module security_ptrace_access_check().

Besides this, the dumpable setting allows the unprivileged user to send e.g. a SIGSEGV signal to the privileged processes and force them to dump core. What happens from here depends on the core dump handler installed in the system. systemd-coredump safely handles such core dumps and the unprivileged user cannot access them. If only core is configured as a core pattern, like it is the case on Debian Linux by default, for example, then the unprivileged user can cause the core file to be created in arbitrary directories, by first changing into them, starting the privileged process, then killing it. The core file will not be readable for the unprivileged user, but it still allows to clutter the file system and maybe even overwrite legit files that are named core.

7.c) Debugging Settings

The privileged programs also offer rich command line settings for enabling debugging output and redirecting it to various locations. Generally, privileged programs should be very careful about what kind of information is leaked to the caller. The debugging logs can contain information that weakens security features (like stack overflow protection) or leak privileged information that has been read in from privileged files.

8) Suggested Fixes

For privileged setuid-root-like binaries the usual precautions should be taken:

• change into a safe current working directory (CWD).
• apply a safe umask (this already happens)
• cleanse the environment from any untrusted variables, only keep a whitelist of vetted variables. E.g. also set a safe PATH.
• make sure none of the interfaces (command line parameters, STDIN data input) offers possibilities for the unprivileged caller to escalate their privileges beyond the scope of what the privileged program is supposed to do.

The last item will likely be the most difficult to realize for the programs in question - especially in the krb5_child helper we expect more attack surface to exist, for example in the handling of the ccache and keytab files. These are dealt with in various other code paths via krb5 library routines that are unaware of the untrusted input. We suggested upstream to carefully think through all the possible inputs and code paths and to tighten them.

We would furthermore strip down the supported command line switches, or limit critical switches to callers that are root, notably the switches that influence debugging and logging as mentioned in section 7.c.

The dumpable setting should be left unchanged in the privilege escalation context.

Finally we suggest to clearly document what can be expected of the privilege separation feature and how the privileged helpers need to be packaged in order to achieve a safe installation (especially that they must not be world executable). This already happened in the description of the 2.10.1 bugfix release.

9) Situation on Other Distributions

We looked into a number of other Linux distributions and found that on Fedora, Debian and Ubuntu the SSSD privilege separation is not currently used. On Arch Linux the current 2.10.0 version is used together with privilege separation, though, which is affected by the issues covered in this report. Upstream informed us that there are plans for Fedora Linux to use the privilege separation feature soon as well.

10) Timeline

11) References

• sssd GitHub project
• sssd 2.10.1 release containing a first batch of fixes addressing issues from this report
• Pending hardening pull request containing further fixes

The openSUSE community will celebrate the 5-year anniversary of the openSUSE Bar on Dec. 19. Join people in the bar and celebrate this social space where open-source enthusiasts, developers and like minded individuals can come together to discuss open source and other topics.

The bar has become more than just a meeting place; it is a space to collaborate, connect and a welcoming atmosphere for sharing ideas. For years, the space has had countless informal meetups and networking events, celebratory moments after openSUSE milestones and is a place for openSUSE fans to gather.

People are invited to join in the celebration and to share memories or stories of their experience in the openSUSE Bar.

You can find a video about the beginning of the openSUSE Bar from a talk at openSUSE Conference 2022.

CentOS Stream 10 and EPEL 10 just became available, and as usual, I tried to build syslog-ng as soon as possible. For now it is available in my git snapshot repository, but I am also planning to make it available in EPEL 10 soon.

Read more at https://www.syslog-ng.com/community/b/blog/posts/test-syslog-ng-on-epel-10

I am delighted to announce that I am mentoring Adetoye Anointing for the December 2024 round of Outreachy. Anointing will be working on librsvg, on implementing the SVG2 text layout algorithm. This is his first blog post about the internship.

There is a lot of work to do! Text layout is a complex topic, so rather than just saying, "go read the spec and write the code", Anointing and I have decided to have a little structure to our interactions:

• We are having two video calls a week.

• During the calls, I'm sharing my screen to walk him through the code.

• I'm using my friend Abrahm's Pizarra and a Wacom tablet to have a "digital chalkboard" where I can quickly illustrate explanations while Anointing and I chat:

• Conveniently, Pizarra also produces SVG files from whatever you doodle in it, so it's easier to include the drawings in other documents.

• We are using a shared document in pad.gnome.org as a development journal. Here I can write long explanations, leave homework, link to stuff, etc. Anointing can put in his own annotations, questions, or anything else. I'm hoping that this works better than scrolling through a Matrix chat channel.

I have big hopes for this project. Please welcome Anointing if you see him around the Rust ♥️ GNOME channel!

Dear Tumbleweed users and hackers,

As the end of the year approaches, many contributors are busy in their private lives. Depending on where they are, some might go skiing, some will use the time to visit friends and families, and others will use their free time to contribute to Tumbleweed. Whatever everybody decides to do during this time, do it with a lot of fun! For week 50 at least, people are still around and busy as we could publish 6 snapshots (1205, 1206, 1208, 1209, 1210, and 1211)

The most relevant updates/changes delivered as part of those snapshots were:

• Qt 6.8.1
• liibvirt 10.10.0
• Xen 4.19.1
• Mesa 24.3.1
• Python 3.11.11
• LLVM 19.1.5
• libeconf 0.7.5
• GStreamer 1.24.10

In the staging area, we currently see these items tested: depending on the people still working on those items, they might be delivered during this year or early next year

• Ruby 3.4 (Release date upstream is December 25); we currently test RC1
• KDE Gear 24.12.0
• Linux kernel 6.12.4
• Systemd 257
• Rails 8.0

A recent back-and-forth on Windows 11’s hardware requirements and the end-of-life timeline for Windows 10 leaves millions of users frustrated and uncertain about their next steps.

With millions of PCs being labeled by mainstream media as becoming obsolete and potential extended security updates costing users even more, the need for a reliable and sustainable alternative has never been greater.

Linux distributions like openSUSE offer a clear and practical solution. It eliminates the risks of vendor lock-in and avoids the pitfalls of Microsoft’s opaque and ever-changing policies.

The recent uncertainty around Microsoft’s policies underscores the challenges of depending on a company that prioritizes profits over a user’s fundamental needs, which is the ability to use their existing hardware and software effectively.

Microsoft initially doubled down on strict hardware requirements for Windows 11, requiring Trusted Platform Module (TPM) 2.0. In a surprising reversal, the company issued instructions for installing Windows 11 on incompatible PCs, which can leave users even more confused.

This apparent change now is undermined by caveats like updates may not be available for unsupported PCs, and the company has openly warned that such installations could lead to system malfunctions. For many, the message is clear; Upgrade to Freedom! Upgrade to openSUSE!

Microsoft deserves some credit for extending some support, avoiding responsibility for one of the largest preventable e-waste surges in history caused by a software upgrade. However, these efforts do little to address the broader challenges impacting millions of users and the wider consequences for consumers and the environment.

The case for Linux and openSUSE is clear. Linux provides viable, cost-effective and sustainable alternatives. Users can enjoy a free, open-source operating system that doesn’t require costly upgrades or restrictive hardware requirements with installing openSUSE. Here are a few things users that want to transition can consider:

• Complete Transparency: Linux distributions like openSUSE are governed by open-source principles, ensuring clear and consistent development.
• No Forced Obsolescence: openSUSE supports a wide range of hardware like modern machines to older PCs that allow users to extend the life of their devices.
• Cost Savings: openSUSE is free to use, with no licensing fees or hidden subscription costs for extended support.

By switching to Linux, users can help combat e-waste as every PC saved from a landfill is a win for the environment.

Transitioning to Linux is easier than people think and openSUSE is one of the most user-friendly distributions that provides comprehensive tools for installation and configuration.

• Back Up Your Data: Safeguard important files before transitioning.
• Download openSUSE: Visit get.opensuse.org to choose between Leap (stable, less updates) or Tumbleweed (rolling updates, several).
• Install openSUSE: Create a bootable USB and follow the guided installation process.
• Explore Applications: Discover free alternatives to popular software, such as LibreOffice for productivity, GIMP for image editing, and Steam for gaming.

Take control of your tech future and embrace the ability to Upgrade to Freedome with openSUSE. Your next step is just a click away - get.opensuse.org.

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

Most people don’t give much thought to their operating system, but with Windows 10 support ending in October 2025, many will start searching for alternatives that keep them secure without spending more than $100 for a software upgrade or on hardware that still works perfectly.

User-friendly Linux distribution like openSUSE and others offer an excellent solution for everyday tasks like social media, video conferencing, web browsing and more.

If you’re a casual computer user wondering whether you can accomplish the same tasks on Linux that you’ve been doing on Windows, the answer is a resounding YES!

From messaging apps like Telegram to video conferencing with Zoom, openSUSE has you covered. This guide will show you how easy it is to get started with Linux and continue using the apps and tools you’re familiar with.

Get the below applications as a Flatpak in the software center of your desktop environment.

Web Browsing: Chrome, Firefox, Brave, and More

Browsing the web on Linux is just as simple as it is on Windows or macOS. openSUSE supports a wide range of web browsers, including some of the most popular names in the market.

• Mozilla Firefox comes pre-installed with most Linux distributions, including openSUSE. It’s fast, privacy-focused, and supports all major web standards, making it perfect for everything from casual browsing to online shopping and video streaming.
• Google Chrome is available on Linux and can be installed easily on openSUSE. If you’re used to Chrome’s features, including syncing bookmarks and settings across devices, you’ll feel right at home.
• Brave is another great option for privacy-conscious users. It blocks trackers and ads by default and gives people a fast and secure browsing experience. Brave is also easy to install on openSUSE. All these browsers support extensions and features you’re already familiar with, so switching to Linux won’t feel like a big leap.

Social Media Apps: Telegram, Discord, and More

Staying connected on social media is easy, especially getting your favorite apps for messaging, video calls and group chats. Whether as a native downloadable app or as Flatpak app, you will hardly know a difference.

• Telegram is available for Linux and can be installed directly from the openSUSE software repositories. It works just like the version you’re used to. It allows you to chat, make voice calls and share media with your contacts.
• Discord, a popular platform for gamers and communities, this also works seamlessly on Linux. You can download the Linux version from the Discord website or install it as a Flatpak for easy updates. Whether you’re chatting with friends or joining online communities, Discord on openSUSE is just as powerful as its Windows counterpart.
• Signal, a privacy-focused messaging app, is available for Linux and ensures that your chats are secure with end-to-end encryption. It’s a great alternative to WhatsApp for privacy-conscious users.

Video Conferencing: Zoom and Alternatives

Video conferencing has become a staple for work and personal use, and openSUSE has strong support for popular platforms like Zoom and others.

• Zoom offers a Linux version that works just like the Windows app. You can download it from Zoom’s official website or use the Flatpak version. Whether you’re attending work meetings, online classes or virtual hangouts with friends, Zoom on openSUSE is fully functional and reliable.

• Jitsi Meet is a free, open-source alternative to Zoom that doesn’t require any installation. You can use it directly from your web browser. The project even uses it for its online bar making it a quick and easy option for video conferencing without the need for additional software. Visit the openSUSE Bar and the may be some people there ready to explain how easy it is to move to Linux.
• Google Meet and Microsoft Teams are also fully supported on Linux via web browsers like Chrome or Firefox, so you can join meetings without any issues. There is even an unofficial Flatpak app for Teams.

Email: Thunderbird, Evolution, and More

Managing your email is easy through the browser or on with several great apps to choose from.

• Mozilla Thunderbird is a popular email client that comes pre-installed on many Linux distributions, including openSUSE. It supports multiple email accounts, calendars and task management, which makes it great for everyday use.
• Evolution is another feature-rich email client that supports Microsoft Exchange, Google accounts, and more. It’s an option if you need advanced email, calendar, and task management features.
• Gmail, Outlook, and other web-based email services are fully accessible via your preferred browser, just as they are on Windows.

Streaming and Multimedia: Spotify, VLC and More

Linux supports popular platforms for streaming music, videos and other media.

• Spotify has an official Linux client that you can install on openSUSE. It works the same as it does on other operating systems, giving you access to your playlists, podcasts and favorite music.
• VLC Media Player is the go-to app for playing virtually any media file. Whether you’re watching movies, TV shows or home videos, VLC’s powerful playback features make it a top choice on a Linux distribution.
• YouTube and other streaming services, such as Netflix, Hulu, and Disney+, are fully supported on Linux via web browsers like Chrome or Firefox.

File Sharing and Cloud Storage: Dropbox, Google Drive, and Nextcloud

Managing your files and cloud storage is simple on openSUSE.

• Nextcloud is a popular open-source alternative to commercial cloud storage services. It allows you to host your own cloud storage solution, giving you full control over your files.
• Dropbox has a Linux client that integrates seamlessly with your desktop and allows you to sync files just as you would on Windows or macOS.
• Google Drive can be accessed through the web browser.

How to Install

Users transitioning from Windows 10 to openSUSE should know it has the same functionality for common tasks like browsing, messaging, video conferencing, and media streaming, but without the need for expensive hardware and software upgrades. Here is an easy step-by-step guide to downloading software on your openSUSE Linux distribution:

KDE Plasma: Using Discover Software Center

KDE Plasma’s default software center is called Discover, which provides an easy way to search for and install applications.

Plasma Step 1: Open Discover

1. Click on the Application Launcher (bottom-left corner of your screen, represented by a green chameleon logo or KDE logo).
2. Type Discover in the search bar, and click on the Discover app to open it.

Plasma Step 2: Search for Software

1. Once Discover is open, you’ll see a search bar at the top.
2. Type the name of the software you’re looking for, such as “Firefox,” “Telegram,” or “Zoom.”

Plasma Step 3: Install the Application

1. Click on the application from the search results.
2. Click the Install button.
3. Wait for the installation process to complete. Once done, the Install button will change to Launch.

Plasma Step 4: Launch the Application

1. You can launch the newly installed application from the Discover window by clicking Launch, or find it in your Application Launcher.

GNOME: Using GNOME Software Center

GNOME’s default software center is called GNOME Software, which functions similarly to an app store.

GNOME Step 1: Open GNOME Software

1. Click on Activities in the top-left corner of your screen.
2. Type Software in the search bar, and click on GNOME Software to open it.

GNOME Step 2: Search for Software

1. At the top of the GNOME Software window, there’s a search bar.
2. Type the name of the software you want to install, such as “Brave,” “Signal,” or “Spotify.”

GNOME Step 3: Install the Application

1. Select the application from the search results.
2. Click the Install button.
3. GNOME Software will handle the download and installation. Once finished, you can launch the app directly from the software center.

GNOME Step 4: Launch the Application

1. After installation, you can click the Launch button in the software center, or find the app in the Activities overview by searching for it.

Whether you’re using KDE Plasma or GNOME, installing software on openSUSE is straightforward with the software centers. Both Discover (KDE) and GNOME Software provide user-friendly interfaces that allow you to search for, install, and manage your applications just like you would in an app store. This makes it easy for users transitioning from Windows 10 to feel comfortable using their new Linux system for everyday tasks.

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

Users of openSUSE can now rely on the built-in switcherooctl tool for GPU switching, which is already integrated into our distributions with major desktop environments like GNOME and KDE Plasma.

This is a game changer because it eliminates the need for additional tools and simplifies multi-GPU management while enhancing compatibility and performance with users’ systems.

For years, tools such as suse-prime and bbswitch have been staples in managing NVIDIA Optimus laptops and multi-GPU systems, but advancements in kernel drivers and desktop environments have made these tools unnecessary in most cases.

Installations of openSUSE now handle these configurations out of the box, whether using the open-source Nouveau driver or NVIDIA’s proprietary drivers.

In a recent update on multi-GPU systems, users are encouraged to move away from legacy tools like suse-prime, bbswitch, and bumblebee, as they can cause more harm than good on modern systems.

The recommended solution is switcherooctl, which is a lightweight userspace utility designed to manage GPU switching on systems with multiple GPUs. It integrates well with Wayland and Xorg; its functionality extends across both Intel + NVIDIA and AMD + NVIDIA setups. By using switcherooctl, users can easily select which GPU to use for specific applications and eliminate the need for complex scripts or environment variables.

Benefits of switcherooctl

• Seamless Integration: Unlike older tools, switcherooctl is designed to work natively with modern Linux systems and desktop environments. This ensures a smoother user experience without requiring complex configurations.

• Improved Performance: Users can specify which GPU to use for specific tasks, so switcherooctl enables optimal performance. Compute-heavy applications, such as gaming or 3D rendering, can utilize the discrete GPU, while less intensive tasks default to the integrated GPU to save power.

• Enhanced Power Management: Switching back to the integrated GPU when the discrete GPU is not needed conserves battery life and makes it ideal for laptops and portable systems.

• Wayland and Xorg Compatibility: With increasing adoption of Wayland, having a tool that supports both Wayland and Xorg ensures compatibility across a broad range of systems and setups.

• Cross-Vendor Support: The Intel + NVIDIA or AMD + NVIDIA configuration make the systems more versatile for all users.

Users should being embracing switcherooctl for multi-GPU management as some of the older tools like suse-prime, bbswitch and bumblebee are likely to be phased out.

Users of openSUSE can now rely on the built-in switcherooctl tool for GPU switching, which is already integrated into our distributions with major desktop environments like GNOME and KDE Plasma.

This is a game changer because it eliminates the need for additional tools and simplifies multi-GPU management while enhancing compatibility and performance with users’ systems.

For years, tools such as suse-prime and bbswitch have been staples in managing NVIDIA Optimus laptops and multi-GPU systems, but advancements in kernel drivers and desktop environments have made these tools unnecessary in most cases.

Installations of openSUSE now handle these configurations out of the box, whether using the open-source Nouveau driver or NVIDIA’s proprietary drivers.

In a recent update on multi-GPU systems, users are encouraged to move away from legacy tools like suse-prime, bbswitch, and bumblebee, as they can cause more harm than good on modern systems.

The recommended solution is switcherooctl, which is a lightweight userspace utility designed to manage GPU switching on systems with multiple GPUs. It integrates well with Wayland and Xorg; its functionality extends across both Intel + NVIDIA and AMD + NVIDIA setups. By using switcherooctl, users can easily select which GPU to use for specific applications and eliminate the need for complex scripts or environment variables.

Benefits of switcherooctl

• Seamless Integration: Unlike older tools, switcherooctl is designed to work natively with modern Linux systems and desktop environments. This ensures a smoother user experience without requiring complex configurations.

• Improved Performance: Users can specify which GPU to use for specific tasks, so switcherooctl enables optimal performance. Compute-heavy applications, such as gaming or 3D rendering, can utilize the discrete GPU, while less intensive tasks default to the integrated GPU to save power.

• Enhanced Power Management: Switching back to the integrated GPU when the discrete GPU is not needed conserves battery life and makes it ideal for laptops and portable systems.

• Wayland and Xorg Compatibility: With increasing adoption of Wayland, having a tool that supports both Wayland and Xorg ensures compatibility across a broad range of systems and setups.

• Cross-Vendor Support: The Intel + NVIDIA or AMD + NVIDIA configuration make the systems more versatile for all users.

Users should being embracing switcherooctl for multi-GPU management as some of the older tools like suse-prime, bbswitch and bumblebee are likely to be phased out.