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.

Table of Contents

• Introduction
• Keepalived Follow-up Review
  • Temporary File Handling
  • D-Bus Implementation
• DKIMproxy Symlink Attack
  • Files Added on Packaging Level
  • Pre- or Post-Scripts in systemd Services
  • Privilege Separation added after the Fact
• Handling of a Vulnerability Report in MirrorCache (CVE-2024-49505)
• Issues with Temporary Files in Hardinfo2
• Aeon-Check Encryption Key in Fixed Temporary File (CVE-2024-49506)
• SDDM Follow-Up Review of D-Bus Interface
• Libcgroup Revisited
• Supergfxctl D-Bus Service
• Systemd v257 Polkit for Varlink IPC
• Miscellaneous
• Conclusion

Introduction

Welcome to the second edition of our new spotlight series. With these posts we want to give you an insight into activities of the SUSE security team beyond major security findings for which we are publishing dedicated reports. Autumn is always a busy time at SUSE, when new service pack releases and new products are prepared. This results also in an increased amount of review requests arriving for the SUSE security team. This time we will be looking at various D-Bus interfaces, Polkit authentication, temporary file handling issues, a small PAM module and setgid-binary, Varlink IPC in systemd as well as some other topics.

Keepalived Follow-up Review

In bsc#1218688 we looked into Keepalived, a load-balancing software written in C. A colleague in the team noticed suspicious handling of temporary files in /tmp and asked for a more in-depth review.

Temporary File Handling

The creation of temporary files in Keepalived is indeed a bit peculiar. The make_tmp_filename() helper function takes the basename of a temporary file and returns a path to this file in $TMPDIR. An example use would be make_tmp_filename("keepalived.json") and the function will return /tmp/keepalived.json. This can easily lead to unsafe temporary file creation.

In the code the resulting filenames are always coupled with another utility function fopen_safe(), though. This function intercepts attempts to open files for writing ("w" mode) and calls the mkostemp() function behind the scenes to safely create a temporary file. The resulting file will then not be used as-is, though, but will be rename()‘d to the expected predictable filename. This is safe, because rename() will not follow symlinks or otherwise reuse the target path, but simply replace it.

D-Bus Implementation

Keepalived also implements a D-Bus system service running as root. Our team reviewed this component many years ago, which led to multiple CVE assignments. Therefore it seemed like a good idea to have a fresh look at the current situation, while we’re at it. We couldn’t find any problems, though. The code is non-trivial but robust. The D-Bus methods can only be called by root. Only some D-Bus properties can be accessed by unprivileged users, but they are not sensitive in nature.

DKIMproxy Symlink Attack

Our team is monitoring changes to systemd services across all of openSUSE Tumbleweed. One such change occurred in DKIMproxy and led us to bsc#1217173. DKIMproxy is a proxy designed for the Postfix mail server. It implements the DKIM standard for signing outgoing email or verifying incoming email.

The package’s systemd service is not part of the upstream sources, but has been added by the package maintainer on packaging level in the Open Build Service. In this service unit a shell script is executed via ExecStartPre with root privileges, while the actual service runs with the lowered privileges of a dedicated service user and group. The shell script performs naive write operations in a directory owned by the unprivileged user. Therefore the unprivileged user can prepare symlink attacks to cause arbitrary file overwrite in the system, as soon as the script is executed again. The content that is written is not controlled by the attacker, therefore this only has denial-of-service impact and does not allow to raise privileges.

We can observe a number of aspects in this case that, based on our experience, represent typical patterns. In the following sections we will look at these in more detail.

Files Added on Packaging Level

Assets like configuration files, scripts or code that are added on packaging level have an increased probability of introducing problems. Some of the reasons for this could be:

• there are less people that review such contributions.
• the process for adding these files is less formalized than e.g. in a GitHub project.
• packagers that add such files might be lacking knowledge about the upstream project.
• packagers might accept such files from others that want a certain feature or behavior and don’t know exactly what it does.
• packagers might take over such files from other Linux distributions, assuming that they are of high quality.

Since we identified that such packaging assets carry an increased risk for issues, we are monitoring additions of and changes to such files in the Open Build Service to look out for problems proactively.

Pre- or Post-Scripts in systemd Services

When privilege separation is in place for a systemd service, we can often find such ExecStartPre and ExecStartPost scripts that are run with raised privileges. This mixture of two different security domains can easily introduce local security issues. This risk is further increased by the fact that these programs are often shell scripts that offer no built-in mechanisms to safely access files owned by unprivileged users as root.

Privilege Separation added after the Fact

Especially in older software that was initially designed to run with full root privileges, privilege separation is sometimes only added as an afterthought, or an unofficial downstream add-on on packaging level. On the surface, such setups often seem to provide privilege separation, i.e. one or more components are running as non-root accounts. This privilege separation can often be easily circumvented as soon as the unprivileged account is compromised, however.

Such weak privilege separation can still offer some level of protection and is usually an improvement over services running as full root. Still, the lack of robustness means that a false promise is given to administrators: namely, that strong separation of privileges exists for such services. The defense in depth is lacking, though, and a change of security scope can happen. Thus, such issues are usually considered worthy of a CVE assignment. In our team we assign or request CVEs for such issues on a case-by-case basis, depending on the severity of the issue, the popularity of the affected software and so on. In the case of DKIMproxy only a denial-of-service can happen and the software is not that widespread, thus we decided not to assign a CVE for it.

Handling of a Vulnerability Report in MirrorCache (CVE-2024-49505)

We have been privately approached by security researcher Erick Fernando about a reflected XSS vulnerability in the openSUSE MirrorCache repository. MirrorCache is a web server that redirects download requests to a mirror according to configuration. We handled the report in bsc#1232341 and assigned CVE-2024-49505 to it. The responsible maintainer applied a fix for the issue and our team member Paolo Perego verified the patch.

Luckily the MirrorCache project is not part of any official products or server side infrastructure of SUSE. We want to thank Erick Fernando again for reaching out to us and reporting this issue.

Issues with Temporary Files in Hardinfo2

Hardinfo2 is a utility to obtain hardware information on Linux, create reports from that data and compare different systems for benchmarking. Hardinfo2 has been newly packaged for openSUSE Tumbleweed in October, and the following lines showed up in our systemd monitoring:

RPM: hardinfo2-2.1.14-1.1.x86_64.rpm on x86_64
Package: hardinfo2
Service path: /usr/lib/systemd/system/hardinfo2.service
Runs as: root:root
Exec lines:
    ExecStart=/bin/sh -c "
        cat /proc/iomem >/tmp/hardinfo2_iomem;
        chmod a+r /tmp/hardinfo2_iomem;
        cat /proc/ioports >/tmp/hardinfo2_ioports;
        chmod a+r /tmp/hardinfo2_ioports;
        chmod a+r /sys/firmware/dmi/tables/*;
        modprobe -q spd5118;modprobe -q ee1004;modprobe -q at24 || true"

The use of fixed temporary file paths sticks out right away, so we created bsc#1231839 to handle the issues resulting from this. By default, kernel protections like protected_symlinks prevent more severe issues like overwriting system files, which would lead to denial-of-service. Even with these protection measures, a local user can pre-create these files and Hardinfo2 will then use the attacker controlled data found in them, causing integrity violation.

Furthermore this logic causes information leaks. The data from /proc/ioports is made world-readable via the temporary file /tmp/hardinfo2_ioports. By default this information is already public in /proc on openSUSE. But it seems on some systems this was not the case, because Hardinfo2 performs these steps to allow unprivileged processes to access that data in /tmp. Another information leak is the chmod a+r operation for /sys/firmware/dmi/tables/*. The permissions of pseudo files should not be altered in a drive-by fashion by system services this way.

We reported the issues to upstream, which quickly worked on improvements in these areas. The shell code has been moved into a proper script named hwinfo2_fetch_sysdata. The problematic files in /tmp are now placed into a dedicated directory in /run/hardinfo2. Users that want to use hardinfo2 now need to be a member of a newly introduced “hardinfo2” group to be able to access the data placed into this directory. The permissions of files in /sys are no longer changed.

Upstream created a new release 2.2.1 containing the changes. We did not request a CVE for these issues, since the biggest impact they can have by default is integrity violation of Hardinfo2 itself.

Aeon-Check Encryption Key in Fixed Temporary File (CVE-2024-49506)

Aeon-Check is a small utility used in openSUSE Aeon. Currently it consists only of a simple bash script invoked via a systemd unit. This script can detect a bug in the TPM-based LUKS disk encryption setup and fix it. To this end, an additional LUKS key slot is temporarily added to the root LUKS device:

keyfile=/tmp/aeon-check-keyfile
dd bs=512 count=4 if=/dev/urandom of=${keyfile} iflag=fullblock
chmod 400 ${keyfile}

<snip>

# Writing keyfile to slot 31 (end of the LUKS2 space) to avoid clashes with any customisation/extra keys
cryptsetup luksAddKey --token-only --batch-mode --new-key-slot=31 ${rootdev} ${keyfile}

The temporary file used to store the ephemeral LUKS key has a fixed filename in /tmp. Fortunately the script has the errexit option set; combined with the protected_regular and protected_symlinks kernel features, no unsafe use of an already existing file in that path will succeed. Without the kernel protection, though, another local user could pre-create this file, and intercept or stage the data used as temporary LUKS key. Even then the chances for exploitation are small, since this systemd service typically only runs once during boot, and the time window during which the temporary LUKS key is valid is short.

Since LUKS encryption is a sensitive area, we still decided to assign a CVE for the issue. We handled the problem in bsc#1228861, and a simple bugfix has been made by the author of the script to use mktemp for safe creation of the temporary file holding the LUKS key data.

SDDM Follow-Up Review of D-Bus Interface

The openSUSE package for the SDDM display manager has been forked for the openSUSE Kalpa flavour. This made a new D-Bus service whitelisting necessary, which was requested in bsc#1232647. The sddm-kalpa package is a Wayland-only version of SDDM, but the sources used in the package are the same as for regular SDDM.

We still used this opportunity to take a fresh look at the situation in SDDM. The D-Bus service shipped with it is practically only a skeleton without implementation. Only a single D-Bus method SwitchToGreeter() is implemented. There is no Polkit authorization, which means that any user can trigger the logic to switch to the greeter. While this situation is not ideal, it is not critical. Therefore we accepted the new package.

Libcgroup Revisited

Libcgroup is a library and set of utilities for using control groups on Linux systems. These days systemd is taking care of this job and, since libcgroup upstream was unmaintained, the package was dropped from openSUSE in 2018. We received a request to reintroduce libcgroup in bsc#1231381. Upstream is active again and there seem to exist some use cases for the package.

Our team was involved because the package contains a setgid binary and a PAM module. We also had a look at the main daemon cgrulesengd, which is running as root. At startup, the daemon iterates over all running processes in /proc and assigns them to control groups according to configuration. Then a netlink socket is set up to obtain events from the kernel about newly created processes and exec() events. These new processes will also be placed into control groups based on configuration.

The approach taken by the daemon is subject to race conditions by design, which is also kind of documented in the upstream repository. Entries in /proc/<pid> can disappear or change security scope e.g. when setuid-root binaries are involved. The configuration is matched to processes based on their name as found in /proc/<pid>/status and the process’ effective uid and gid. We can imagine that a dedicated local attacker will be able to have the libcgroup daemon wrongly assign an unprivileged process to a control group destined only for privileged processes e.g. by exploiting race conditions and using setuid-root binaries like sudo. Since this is by design, we did not approach upstream about this possibility. Users of the package should be aware that this could result in local DoS attack vectors, though.

The setgid program cgexec found in the package is a simple program that only forwards an IPC request to the libcgroup daemon, asking it to mark the calling process as “sticky”. The binary requires special group permissions to be allowed to connect to the UNIX domain socket of the libcgroup daemon. The extra privileges are dropped right after connecting to the socket. The socket is also closed right after sending the request. So escalating group privileges, leaking the socket file descriptor or otherwise influencing the IPC communication done by cgexec is not a concern.

The PAM module shipped with the package only implements a PAM session type hook. It calls into the libcgroup library to assign the calling process to an appropriate control group, thereby placing new sessions into control groups according to configuration.

Supergfxctl D-Bus Service

Supergfxctl is a D-Bus daemon that takes care of low level kernel settings in NVIDIA hybrid GPU systems. The software has been newly packaged in November and we’ve been asked to whitelist it in bsc#1232776.

There are some worries with this daemon, mostly with regards to local denial-of-service attack surface. For example there is some racy logic in the daemon that looks up and kills all processes that have /dev/nvidia0 open. The D-Bus methods allow to completely control the daemon’s configuration and are by default accessible to all members of the sudo, users, adm and wheel groups. This selection of groups is rather broad and surely targeted towards maximum compatibility with various Linux distributions. It is unlucky, because there is a possibly large range of users that are allowed to control the supergfxctl daemon this way.

To make the new service acceptable for openSUSE we asked the packager to limit access to the D-Bus service to members of the video group instead. Users that are in the video group have increased privileges with regards to accessing the video hardware in the system, thus it is a better match for supergfxctl than just the users group, for example. An even better approach would be to add Polkit authentication in this D-Bus service, but this is something that would require larger efforts by upstream and is not currently in sight.

Systemd v257 Polkit for Varlink IPC

We routinely review additions to the D-Bus and Polkit interfaces in new systemd releases. This time we have been asked to check a few new Polkit actions in systemd-containerd, systemd-homed, systemd-networkd, and systemd-resolved. Interestingly these daemons have all been migrated from using D-Bus to using Varlink for Inter-Process-Communication (IPC).

In our experience, the code quality of systemd components is generally high. These additions were no different. All new Polkit actions are limited to auth_admin authorization, thus no additional attack surface is made available to unprivileged local users.

At first sight the switch to Varlink doesn’t change much security-wise: there are still individual methods in a service that can be invoked by clients and some or all of them can be protected by Polkit authentication. The switch to Varlink requires new glue code for the authorization against Polkit, however. Thus we looked deeper into how this is done in systemd.

When using D-Bus the SystemBusName Polkit subject is used, which identifies a client process by its D-Bus sender address. This way polkitd can securely identify the credentials of the client process by asking the dbus-daemon about the credentials of the owner of the UNIX domain socket used by the client to connect to D-Bus.

With Varlink this is no longer possible. Instead the UnixProcess subject is used to identify the client. This made us a bit nervous at first, because the UnixProcess subject is deprecated and often used insecurely. The problem here is that polkitd needs to use racy logic to lookup the process by PID in the /proc file system and extract its credentials. Former SUSE security team member Sebastian Krahmer discovered this in 2014, and it affected a lot of programs that implemented Polkit actions using this subject. The use of this subject in systemd to authenticate Varlink methods is robust, though. The client’s credentials are obtained from the UNIX domain socket underlying the Varlink connection, and thus via the kernel. Also a pidfd can be passed to Polkit nowadays, which allows polkitd to operate in a race-free fashion on the client process.

As the Polkit glue code turned out all right we accepted the changes and whitelisted the additions in systemd v257.

Miscellaneous

The following reviews didn’t yield much of interest, so we’re just providing a short listing here for reference:

• GNOME Remote Desktop follow-up review (bsc#1230406). Last time we looked into GNOME Remote Desktop, we found a couple of issues in its D-Bus implementation. Another D-Bus service “org.gnome.RemoteDesktop.Configuration.service” has been added in the meantime and we have been asked to take a look. The new service is rather small and all of its methods are protected by a single Polkit action “org.gnome.remotedesktop.configure-system-daemon”, which requires Polkit auth_admin authentication. So there shouldn’t be additional attack surface for local non-privileged users in the system. Overall the complexity of GNOME in this area continues to grow, though, and it is a challenge to review it fully without being an expert in GNOME and the remote desktop protocols.
• Additional D-Bus and Polkit features in the UPower Daemon (bsc#1232835). This just adds a boolean switch to control whether a battery charging threshold should be active or not. It is allowed for users in a local session without authentication.
• Added “memoryinformation” D-Bus Method in kinfocenter6 (bsc#1231659). Our packager backported this feature from a newer upstream version. This new action allows users in a local session to obtain the output of dmidecode --type 17, which contains some low-level information about physical RAM in the system. The implementation of this is straight-forward and we had no worries accepting this change.

Conclusion

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 winter issue of the spotlight series to be available in about three months from now.

Dear Tumbleweed users and hackers,

We’re quickly approaching the end of the year, and I hear more and more people ‘preparing for the holiday’. As with every year, this season will likely slow down Tumbleweed. There are more important things to tend to than sending updates to Factory over and over, something I am sure all readers will support. Our maintainers deserve a break every now and then—after fixing the most critical bugs. This week, the developers are still in full swing and are sending submissions to Factory. The Release Team produced 4 working snapshots (1129, 1202, 1203, and 1204.

The most relevant changes delivered to the users during this week were:

• Mozilla Firefox 133.0
• LibreOffice 24.8.3.2
• SQLite 3.47.1
• elfutils 0.192
• mozjs 128.5.1 (JS engine used by GNOME-Shell)
• systemd 256.9
• libcap 2.73
• Python setuptools 75.6.0

Of the advertised things from last week, most notably systemd and kernel 6.12 have not made it into any snapshot yet: both started showing issues around TPM measuring which have been flagged by openQA and are actively worked on by the developers. Currently, the release team is testing those updates in the staging areas:

• Linux kernel 6.12.3
• Systemd 257.x
• Rust 1.83
• Python 3.11.11, 3.12.8
  

The openSUSE community is excited to announce the official release of Leap Micro 6.1.

Leap Micro continues its alignment with SUSE Linux Enterprise Micro, ensuring robust container and virtual machine hosting capabilities. The release has a new opensuse-migration-tool, which simplifies upgrades for smoother transitions between releases. Some enhanced features include reworked jeos-firstboot, soft-reboot support to further minimize downtime, two-factor authentication with cockpit and additional tools like vhostmd for SAP Virtualization.

You might want to check our Leap Micro 6.1 video showcasing fully encrypted disk image with TPM 2.0 chip, and the two factor authentication with cockpit.

The release of Leap Micro 6.1 signals the End of Life (EOL) for Leap Micro 5.5. Users are strongly encouraged to upgrade to either Leap Micro 6.0 or 6.1 to continue receiving updates and support.

For a detailed upgrade guide, visit the openSUSE Wiki or SLE Micro 6.1 Release notes.

The openSUSE community is excited to announce the official release of [Leap Micro 6.1]((https://get.opensuse.org/leapmicro/6.1/).

Leap Micro continues its alignment with SUSE Linux Enterprise Micro, ensuring robust container and virtual machine hosting capabilities. The release has a new opensuse-migration-tool, whic simplifies upgrades for smoother transitions between releases. Some enhanced features include soft-reboot support. Two-factor authentication (TOTP) for PAM logins improves security. There are additional tools like vhostmd for SAP Virtualization and improvements to the jeos-firstboot wizard and more.

The release of Leap Micro 6.1 signals the End of Life (EOL) for Leap Micro 5.5. Users are strongly encouraged to upgrade to either Leap Micro 6.0 or 6.1 to continue receiving updates and support.

For a detailed upgrade guide, visit the openSUSE Wiki or SLE Micro 6.1 Release notes.

Lots of KDE hacking these days, and that comes with compiling large amounts of code. Right now, I am installing, well building from source Plasma Mobile on an “old” laptop so I can test some patches natively on a touchscreen device. The machine has just two cores (hyperthreaded), so builds take rather long, especially if you build Qt and all that 80+ packages that are needed for a fully working Plasma system.
One of the tools that do an incredible job while being super flexible to use is icecream. Icecream (or “icecc“) allows you to distribute your build over multiple machines, it basically ships compile-jobs with all that’s needed to other machines on a local network, meaning you can parallelize your builds.

Icecream has this nice visualization tool, called icecream-monitor which you can stare at while your builds are running (in case you don’t have anyone handy for a sword-fight). In the screenshot you can see manta, the underpowered laptop doing a 32 parallel job build over the network. miro is my heavy workstation, 8 cores and 128GB of RAM, it duely gets the bulk of the work assigned, frame is my (Framework) laptop, which is also quite beefy, gets something to do too, but not taxed as heavily as that build monster in my basement office.
Icecream can be used with most environments that have you run your compiler locally. Different distros are no problem! Just a matching CPU architecture is needed. Icecream does its job by providing its own g++ and gcc binaries, which will relay the build jobs transparently to either your local machine or across the network. So you basically install it, adjust your PATH variable to make sure icecc’s g++ is found before your system’s compiler and start your build. Other machines you want to join in for the fun just need to run icecc-scheduler and they will be automatically discovered as build slaves on your network. If you want to further speed up builds, it works with ccache as well.

Please note that you only want to do this in a trusted environment, we’re shipping executables around the network without authorization!

Recently I was asked why the syslog-ng newsletter looks odd. At first I did not even understand what is the problem. Then I realized that I kept using the same format for the past 14 years, that was optimized for UNIX terminals :-)

So, what is the problem? 14 years ago I was kindly asked by syslog-ng users to use plain text e-mails instead of HTML formatting. Of course it also means that there is no easy way to emphasize titles in the newsletter. For that I started to use a long list of hyphens under the titles, equal length to the title. It all looks perfect in a terminal window, which has fixed width fonts. It definitely looks odd in a GUI e-mail client, which does not use fixed width fonts. Something like this:

This is a really nice title

---------------------------

The lenght of the line and the title are different. Luckily the mailing list archive also uses a fixed width font when showing e-mails. So, if you take a look at the last syslog-ng newsletter, you will see that it looks completely OK: https://lists.balabit.hu/pipermail/syslog-ng/2024-December/026735.html

So, what is next? My suspicion is that over the past decade even the most diehard terminal users started to use graphical e-mail clients (most likely a web browser). Starting next year I’ll switch to HTML formatting, hoping that nobody will complain :-)

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

• FreeBSD audit source for syslog-ng

• Version 4.8.1 of syslog-ng is now available

• Where should I present syslog-ng and sudo?

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2024-12-freebsd-audit-4-8-1-conferences

Release Candidate images of Leap Micro 6.1 can be found at get.opensuse.org.

At this point we’re only awaiting confirmation of the Leap Micro 6.1 maintenance setup prior making an official release; hopefully coming later this week.

Please be aware that the release of Leap Micro 6.1 means the end of life for Leap Micro 5.5.

Users are advised to upgrade to either Leap Micro 6.0 or 6.1 and can find details about release cycle on the openSUSE wiki.

Users upgrading from previous releases can consider our experimental opensuse-migration-tool. The migration tool will be part of Leap Micro 6.1+; users from older release can still get the tool from git.

See our Leap Micro upgrade wiki for more information about upgrade options.

See SLE Micro 6.1 Release notes and a summary for a list of changes in the Leap Micro 6.1 Alpha announcement.

Creative professionals exploring alternatives that allow them to continue working without investing in costly new hardware and software upgrades can look at Linux as the end of Windows 10 approaches.

Distributions and flavors like openSUSE’s Tumbleweed, Leap, Slowroll, Kalpa and Aeon and other Linux distributions offer an excellent platform for creators with a wide variety of powerful, open-source tools designed to meet the needs of artists, designers, photographers, videographers and video editors.

From Indie short films to podcasts, open-source software and tools are available as a Flatpak, AppImage or as a native applications for creative people to create.

Many user-friendly tools are viable alternatives to popular, proprietary commercial applications like Photoshop, Illustrator, Final Cut Pro and others.

This article explores some of the top creative tools available on Linux and how transitioning to openSUSE can help creative professionals maintain, or even improve, their productivity.

Transitioning from Photoshop to GIMP

For many creatives, Photoshop is the go-to application for photo editing and graphic design. However, GIMP is an excellent open-source alternative that provides a wide range of professional-grade features.

GIMP supports many file formats, including PSD and offers powerful tools for retouching, editing and manipulating images. Creative professionals will find familiar features like layers, masks, blending modes and a variety of brushes. GIMP also supports high-bit-depth images and allows users to create professional-quality designs.

GIMP may have a slightly different workflow than Photoshop, but it is flexible, customizable and its plugin support makes it a highly versatile tool for image editing and graphic design. Many users find that GIMP offers all the functionality they need to complete complex projects.

Alternatives to Illustrator: Inkscape

For vector graphics, Inkscape is a known alternative to Illustrator. Inkscape is a powerful, free tool for creating logos, illustrations and scalable graphics. It supports common vector formats, including SVG, AI, and EPS, which make it easy to integrate into existing workflows.

Inkscape’s interface is intuitive for Illustrator users and features many of the same tools, such as the Pen tool, curves, shape tools and layer management. Its active development community ensures frequent updates, and the software is highly customizable through extensions and plugins.

For those focused on scalable design and illustration, Inkscape provides a professional-grade environment without the subscription fees associated with cloud creative services. This saves costs and opens people’s minds to the alternatives that are available.

Video Editing: Kdenlive and Blender

Creative professionals working in video production and editing have strong options to use both Kdenlive and Blender. Kdenlive, which is part of the KDE ecosystem, is a feature-rich video editor that provides tools for cutting, splitting and arranging video clips. It supports multiple video and audio tracks, transitions, effects and keyframe animation, which makes it suitable for everything from simple edits to more complex projects.

Blender is an industry-leading, open-source application meant for those working on 3D animation, video effects or visual effects (VFX). Blender’s capabilities include 3D modeling, animation, rendering and compositing, as well as a fully functional video editor. Blender is widely used in professional studios for film, game development and visual effects, which makes it a powerful option for creative professionals. Blender’s source code is governed by the GNU General Public License, embodying the same principles of freedom and collaboration that drives distributions like openSUSE and others.

Audio Production: Ardour and Audacity

Creative professionals working in music production, sound design or podcasting have options. Software packages like Ardour and Audacity offer powerful audio editing solutions. Ardour is a digital audio workstation (DAW) that supports multi-track recording, mixing and mastering. It is widely used for professional audio production, supporting VST plugins and offers advanced feature sets comparable to Logic Pro and Pro Tools.

Audacity is a simple and easy-to-use tool for audio editing; it’s ideal for basic recording, podcasting and sound editing tasks. It’s perfect for quick edits and simple projects, with support for a variety of audio formats and built-in effects.

3D Modeling and Animation: Blender

Blender deserves a second mention here because of its dominance in the field of 3D modeling and animation. Blender’s comprehensive suite of tools allows users to create everything from character animations to architectural models. It offers sculpting tools, UV unwrapping, rigging, particle simulation, and more.

For creative professionals used to proprietary 3D modeling software like Autodesk Maya or 3ds Max, Blender provides a comparable, if not superior, set of features with the added benefit of being open-source.

Publishing and Layout: Scribus

For professionals in publishing or those who need to create print-ready materials, Scribus is a capable desktop publishing tool. It provides features for designing brochures, books, magazines and other print materials. It’s similar to InDesign and just as functional.

Scribus supports advanced typography, CMYK colors, ICC color profiles and PDF export, which makes it a professional solution for designers working on print projects. With a clean, organized interface, it makes a transition from InDesign relatively smooth.

Why openSUSE?

Besides Windows 10 expiring and having to spend more than $100 USD for an upgrade depending on the country you live in, openSUSE provides a solid environment for creative professionals to transition to a new operating system. It offers stability, security and flexibility that allows users to customize their systems to fit their specific needs. Tumbleweed, which is openSUSE’s rolling release version, ensures access to the latest versions of creative software, while the Leap version offers long-term stability with fewer updates; Leap is ideal for users who prefer to avoid frequent changes.

With software centers and tools like openSUSE’s YaST configuration tool, managing software and updates are incredibly easy; this can be a big advantage for those new to Linux.

Creative professionals can continue producing high-quality work without the need for expensive software subscriptions or hardware upgrades. From GIMP and Inkscape to Blender and Ardour, the open-source Linux ecosystem offers powerful, free alternatives that rival commercial counterparts.

The “Upgrade to Freedom!” campaign is here to help creative people make the switch. By choosing openSUSE, you not only gain access to a suite of professional-grade tools but also extend the life of your hardware and avoid contributing to e-waste.

Now is the perfect time for creative professionals to embrace the freedom of open-source software and continue thriving on Linux.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.Those who would like to order a laptop with Linux, can visit slimbook.com or other providers of Linux machines.