How to Run KDrive AppImage on openSUSE and Fedora
Tired of big tech controlling your cloud storage? Switch to KDrive a privacy-focused, European alternative.
In a world where big tech dominates cloud storage and productivity tools, many of us are seeking alternatives that prioritize privacy, control, and independence. KDrive, a European cloud storage solution, provided by Infomaniak is one such alternative, offering a way to break free from the grip of large corporations while maintaining functionality and security.
However, if you’re using openSUSE or Fedora with SELinux enabled (default) you might encounter a roadblock when trying to run the KDrive AppImage:
error while loading shared libraries: libsentry.so: cannot enable executable stack as shared object requires: Permission denied
This error is a direct result of SELinux’s strict security policies, which, while powerful, can sometimes interfere with legitimate applications. In this post, I’ll guide you through the step-by-step process to resolve this issue, ensuring you can use KDrive seamlessly on openSUSE without compromising on security or independence.
Why does this happen?
KDrive has been built with Ubuntu users in mind and Infomaniak won't officialy support other distributions:
From the Infomaniak website: https://www.infomaniak.com/en/support/faq/617/install-kdrive-on-linux
The kDrive application is officially supported by Infomaniak only on the following configurations:
Ubuntu 22.04 LTS (and higher versions)
Desktop environments: GNOME or KDE
The application may work on other Linux distributions (Debian, Fedora, etc.) or with other desktop environments, but Infomaniak provides no technical assistance for installation or use outside the configurations mentioned above.
SELinux vs. AppArmor
- openSUSE (and RHEL, Fedora, etc.) uses SELinux as its default Mandatory Access Control (MAC) system. SELinux enforces strict policies by default, including blocking processes from enabling executable stacks unless explicitly allowed.
- Ubuntu (and Debian) uses AppArmor by default. AppArmor is less restrictive in this specific case and does not block executable stacks for AppImages, which is why KDrive runs without issues on Ubuntu.
The technical reason
The error occurs because:
- The KDrive AppImage loads the
libsentry.soshared library. - This library requires an executable stack (
execstack) to function. - SELinux’s default policy denies this permission for processes running in the
unconfined_tdomain (which is where AppImages typically run).
Step-by-step solution
This solution is specifically for openSUSE, the process should be almost identical for Fedora. If you need some help, just drop a comment.
Prerequisites
- openSUSE with SELinux enabled (check with
sestatusorgetenforce). - The KDrive AppImage downloaded and made executable (
chmod +x kdrive.appimage). - Root or sudo access to modify SELinux policies.
Step 1: Check the SELinux context of the AppImage
Run the following command to check the SELinux context of your KDrive AppImage:
ls -lZ /path/to/kdrive.appimage
Example output:
-rwxr-xr-x. marco users unconfined_u:object_r:user_home_t:s0 /home/marco/kdrive.appimage
Note the context (user_home_t in this case).
Step 2: Create a custom SELinux policy
SELinux allows you to create custom policies to override default denials. We’ll create a policy to allow the AppImage to enable an executable stack.
Create the policy file
Create a file named mykdrive.te with the following content:
module mykdrive 1.0;
require {
type unconfined_t;
type user_home_t;
type tmp_t;
class process { execstack };
class file { execute };
}
# Allow unconfined_t to enable execstack for its own process
allow unconfined_t self:process execstack;
# Allow unconfined_t to execute files labeled as user_home_t
allow unconfined_t user_home_t:file execute;
# If the AppImage mounts files in /tmp, allow execstack for tmp_t
allow unconfined_t tmp_t:file { execute execstack };
allow unconfined_t tmp_t:process execstack;
Note: The
tmp_trules are included because AppImages often mount their files in/tmp/.mount_*. If your AppImage doesn’t use/tmp, you can omit these lines.
Step 3: Compile and install the policy
Run the following commands to compile and install the policy:
# Compile the .te file into a .mod file
sudo checkmodule -M -m -o mykdrive.mod mykdrive.te
# Package the .mod file into a .pp file
sudo semodule_package -o mykdrive.pp -m mykdrive.mod
# Install the policy module
sudo semodule -i mykdrive.pp
Step 4: Verify the policy
Check if the module is loaded:
sudo semodule -l | grep mykdrive
If the module appears in the list, it’s active.
Step 5: Run KDrive
Now, try running the KDrive AppImage again:
./kdrive.appimage
It should now start without the execstack error.
Step 6: Troubleshooting
If KDrive still fails to run:
-
Check for new denials in the audit log:
sudo ausearch -m avc -ts recentIf you see new denials, update your
mykdrive.tefile to include the missing permissions, then recompile and reinstall the policy. -
Label the AppImage as
bin_t(optional):
If the above doesn’t work, you can label the AppImage asbin_t(for binaries):sudo chcon -t bin_t /path/to/kdrive.appimageThen, update your policy to allow
execstackforbin_t:allow bin_t self:process execstack; -
Temporarily set SELinux to permissive mode (for testing only):
sudo setenforce 0If KDrive runs in permissive mode, the issue is confirmed as SELinux-related. Remember to re-enable enforcing mode afterward:
sudo setenforce 1
Why Doesn’t this happen on Ubuntu?
Ubuntu uses AppArmor instead of SELinux as its default MAC system. Here’s why this matters:
-
AppArmor’s Default Behavior:
AppArmor is less restrictive than SELinux by default. It does not block executable stacks for processes unless explicitly configured to do so. Most AppImages, including KDrive, run without issues under AppArmor. -
SELinux’s Strictness:
SELinux enforces a deny-by-default policy. Any action not explicitly allowed is blocked. This includes enabling executable stacks, which is why you need a custom policy for KDrive. -
Policy Differences:
- SELinux: Requires explicit policies for almost everything, including low-level operations like
execstack. - AppArmor: Focuses on file access and capabilities, and is more permissive for operations like
execstack.
- SELinux: Requires explicit policies for almost everything, including low-level operations like
-
Distribution Choices:
- openSUSE, RHEL, and Fedora prioritize SELinux for its fine-grained control, which is ideal for servers and security-conscious users.
- Ubuntu and Debian prioritize AppArmor for its simplicity and ease of use, especially for desktop environments.
Is this a good thing?
While SELinux’s strictness can be frustrating for desktop users, it’s a powerful security feature:
- Prevents Exploits: Blocking executable stacks can prevent certain types of buffer overflow attacks, where malicious code tries to execute data in the stack.
- Fine-Grained Control: SELinux allows administrators to define exactly what each process can do, reducing the attack surface of the system.
- Mandatory Access Control: Unlike traditional Unix permissions (which are discretionary), SELinux policies are mandatory and cannot be bypassed by users or applications.