How to Run KDrive AppImage on openSUSE and Fedora

Share
X LinkedIn

Tired of big tech controlling your cloud storage? Switch to KDrive a privacy-focused, European alternative.

How to Run KDrive AppImage on openSUSE and Fedora

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:

  1. The KDrive AppImage loads the libsentry.so shared library.
  2. This library requires an executable stack (execstack) to function.
  3. SELinux’s default policy denies this permission for processes running in the unconfined_t domain (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 sestatus or getenforce).
  • 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_t rules 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:

  1. Check for new denials in the audit log:

    sudo ausearch -m avc -ts recent
    

    If you see new denials, update your mykdrive.te file to include the missing permissions, then recompile and reinstall the policy.

  2. Label the AppImage as bin_t (optional):
    If the above doesn’t work, you can label the AppImage as bin_t (for binaries):

    sudo chcon -t bin_t /path/to/kdrive.appimage
    

    Then, update your policy to allow execstack for bin_t:

    allow bin_t self:process execstack;
    
  3. Temporarily set SELinux to permissive mode (for testing only):

    sudo setenforce 0
    

    If 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:

  1. 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.

  2. 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.

  3. 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.
  4. 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.

References