Can not run flatpak apps after Kicksecure update

Can not run flatpak apps after Kicksecure update

/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=raider com.github.ADBeveridge.Raider
bwrap: No permissions to create new namespace, likely because the kernel does not allow non-privileged user namespaces.

Issue confirmed for me too. Zero changes done on Flatpak apps, issue only occured after latest kicksecure piont release 17.2.3.7 update.

Yes. Flatpak and some Appimage cant run :frowning:

1 Like

This sounds like either Kicksecure has a kernel built without unprivileged user namespace creation abilities, or a major AppArmor update came through that is disabling the feature. I’ll look into this later today most likely.

1 Like

it security-misc. I checked. set it to debian and flatpak will stop working

security-misc changed in this release:

kernel.unprivileged_userns_clone=0

Temporary workaround to undo this setting (untested):

sudo sysctl -w kernel.unprivileged_userns_clone=1
1 Like

This is good to have and kept as default, something else should be figured out on how to make flatpak work.

Alpinelinux using the same kernel option:

But they say if you have flatpak permission issue just " add your user to the flatpak group."

https://wiki.alpinelinux.org/wiki/Flatpak#Permission_errors

Why turning off this option is not solution:

Workaround, worked:

[user ~]% sudo sysctl -w kernel.unprivileged_userns_clone=1
kernel.unprivileged_userns_clone = 1
[user ~]% flatpak install org.mozilla.firefox
Looking for matches…
Required runtime for org.mozilla.firefox/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/23.08) found in remote flathub
Do you want to install it? [Y/n]: n 
error: The application org.mozilla.firefox/x86_64/stable requires the runtime org.freedesktop.Platform/x86_64/23.08 which is not installed
zsh: exit 1     flatpak install org.mozilla.firefox
[user ~]% flatpak install io.freetubeapp.FreeTube
Looking for matches…
Required runtime for io.freetubeapp.FreeTube/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/23.08) found in remote flathub
Do you want to install it? [Y/n]: y

io.freetubeapp.FreeTube permissions:
    ipc        network                pulseaudio             x11
    dri        file access [1]        dbus access [2]        bus ownership [3]

    [1] xdg-download
    [2] org.freedesktop.PowerManagement, org.freedesktop.ScreenSaver, org.gnome.SessionManager,
        org.gnome.SettingsDaemon
    [3] org.mpris.MediaPlayer2.chromium.*, org.mpris.MediaPlayer2.freetube


        ID                                     Branch         Op    Remote    Download
 1. [âś“] org.freedesktop.Platform.GL.default    23.08          i     flathub   164.6 MB / 163.8 MB
 2. [âś“] org.freedesktop.Platform.GL.default    23.08-extra    i     flathub    22.6 MB / 163.8 MB
 3. [âś“] org.freedesktop.Platform.Locale        23.08          i     flathub    17.9 kB / 371.6 MB
 4. [âś“] org.freedesktop.Platform.openh264      2.2.0          i     flathub     1.2 MB / 944.3 kB
 5. [âś“] org.freedesktop.Platform               23.08          i     flathub   250.0 MB / 230.9 MB
 6. [âś“] io.freetubeapp.FreeTube                stable         i     flathub   123.4 MB / 114.8 MB

Installation complete.
[user ~]%

I confirm the workaround worked, thanks

Not clear what this is about since they failed to show the error message. I don
t think it’ not a permission issue. The error message is very clear and links to documentation. Permission issue would probably be a different issue. On Debian, there is no flatpak linux user group.

There are only two solutions. Debian and Flatpak are very clear about it. References:

The only options are,

  • A) bubblewrap SUID; or
  • B) kernel.unprivileged_userns_clone=1 Linux sysctl; or
  • C) Not using Flatpak.

As for bubblewrap SUID, quote Flatpak documenation:

This mode is not recommended, and some Flatpak apps and features will not work.

Quote Debian readme:

This can be a security risk: if there are bugs in bubblewrap, it might be
possible for an unprivileged user to get root privileges by running a
setuid version of the bwrap executable. CVE-2020-5291 and CVE-2016-8659
are examples of bugs that had this effect in the past. However, it allows
the kernel to be configured to disallow creation of user namespaces by
unprivileged users, which prevents attacks like CVE-2016-3135 from being
carried out against the kernel. This is a trade-off between different
security risks.

Quote Flatpak documentation:

This is a security trade-off. Disallowing unprivileged use of user namespaces reduces the kernel’s attack surface, which mitigates some attacks; but it also disallows some sandboxing techniques, which prevents other attacks from being mitigated. Making bwrap or flatpak-bwrap setuid root also carries some risk: an attacker might be able to exploit vulnerabilities in bwrap to achieve root privilege escalation.

So there is no perfect solution. However, since SUID is being discouraged by Flatpak, the choice is simple: B) kernel.unprivileged_userns_clone=1 Linux sysctl.

This has been reverted in git:


Background information for developers:

kernel.unprivileged_userns_clone=0 is a Debian specific kernel feature. Not in Linux mainline.

Why Kicksecure-Qubes (and therefore Qubes-Whonix) is unaffected? Because it uses dom0 kernel by Qubes default. And Qubes dom0 provided kernel is not a Debian kernel. Related: Simplify and promote using in-vm kernel · Issue #5212 · QubesOS/qubes-issues · GitHub

Recommended Settings | Linux Kernel Self-Protection Project recommends:

# Disable User Namespaces, as it opens up a large attack surface to unprivileged users.
user.max_user_namespaces = 0

But that will also break flatpak. To break flatpak temporarily, run: sudo sysctl -w user.max_user_namespaces=0. To unbreak, reboot or sudo sysctl -w user.max_user_namespaces=3643. Where number 3643 is coming from? That’s the default that can be seen using: sysctl -a | grep user.max_user_namespaces

This is now in all Kicksecure repositories.

This means after updates + reboot this issue will be resolved.

Thank you very much! I really like this update - it fixed old bugs, and now flatpak works. Kicksecure works great even on my kde plasma :slight_smile:

It doesnt matter, break flatpak or break thunderbird… idea is that this option preventing malicious attacks, breaking it for app/s satisfactory is security nonsense.

workaround mean either giving user extra (even if insecure) instructions because this is user decision to decide or a workaround that can be implemented but keeps up the same security level.

how come this is a good security decision for the users? this is a degrade to the security for just user self satisfactory.

But, if you can’t patch it or think there may indeed be a new version of the vulnerability out there? In that case, you can mitigate it by disabling the ability for unprivileged users to create namespaces. To do this temporarily, in the Debian/Ubuntu world run:

$ sudo sysctl -w kernel.unprivileged_userns_clone=0

To disable it for once and all:

echo kernel.unprivileged_userns_clone=0 | \ sudo tee /etc/sysctl.d/99-disable-unpriv-userns.conf

Personally, I’ve never been keen on granting unprivileged users the ability to create namespaces. As a wise admin once said, "Unless you truly need it, just disable it."

Nasty.

1 Like

FWIW Ubuntu implemented a very similar policy to this using AppArmor. I don’t think Debian 12 will have the needed code for it to work, but their solution to this issue was to make AppArmor able to grant unprivileged user namespace creation privileges to individual apps via AppArmor policies. This is documented at Ubuntu 24.04 LTS (Noble Numbat) Release Notes - Release - Ubuntu Community Hub. Sadly, this solution is not easy to use with AppImages.

IMO it would be worthwhile figuring out how to disable unprivileged userns creation in Kicksecure in a way that doesn’t render many apps unusable. Perhaps if Trixie has the needed code for using AppArmor policies for this, a permissions-granting app could be created and used here.

1 Like

I am sympathetic to nurmagoz’s reasoning here. If kernel.unprivileged_userns_clone=0 helps security, I would think it would be good to have it that way by default for a security-oriented distribution. Users who want to use flatpak can look at documentation on how to make it kernel.unprivileged_userns_clone=1 in order to use flatpak. However, I have alternatives to flatpak that suit my needs, so I guess I am biased.

In regards to appimages breaking, wouldn’t the “–no-sandbox” option for appimages solve the problem? For example, under kernel.unprivileged_userns_clone=0, my appimage for FreeTube does not work if I go to the terminal and type “./freetube_0.21.3_amd64.AppImage”. However, it does work if I type “./freetube_0.21.3_amd64.AppImage --no-sandbox”. Would the appimages that the other commenters are talking about work with the “–no-sandbox” option?

Regardless, I decided to go in and follow nurmagoz’s quoted instructions. However, the command was not working for me.


user@host:~$ echo kernel.unprivileged_userns_clone=0 | \ sudo tee /etc/sysctl.d/99-disable-unpriv-userns.conf

-bash: sudo: command not found

user@host:~$ sudo -i

[sudo] password for user:

root@host:~# echo kernel.unprivileged_userns_clone=0 | \ tee /etc/sysctl.d/99-disable-unpriv-userns.conf

-bash: tee: command not found

I do not know why it was not working. So I ran this command instead to disable it.


user@host:~$ sudo -i

[sudo] password for user:

root@host:~# echo kernel.unprivileged_userns_clone=0 > /etc/sysctl.d/99-disable-unpriv-userns.conf

That command works. So if anyone wants to set kernel.unprivileged_userns_clone=0 instead of the current default of kernel.unprivileged_userns_clone=1, they can do it that way.

kernel.unprivileged_userns_clone=1 by default incompatible with project goals. There was Kicksecure Stable Version User Experience but on the same page I elaborated just now and added a new wiki chapter, Security versus Usability.

Without looking into the details… A sandbox is “usually” a security feature. --no-sandbox would disable the sandbox, i.e. would disable a security feature.

This can be future work.

Yes, it would disable a security feature. Presumably, setting kernel.unprivileged_userns_clone=1 instead of 0 is also disabling a security feature. Anyways, I am not so much offering a recommendation as I am offering a potential way to make appimages work under kernel.unprivileged_userns_clone=0. This is because previous comments said that some appimages were not working under kernel.unprivileged_userns_clone=0.

TOR browser is focused on security. But by default, all scripts in noscript are not disabled - only most basic protection. If you want max protection - change settings. Here is a similar situation, OS should be convenient for new users