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 
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.
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
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,
kernel.unprivileged_userns_clone=1 Linux sysctl; orAs 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
bwraporflatpak-bwrapsetuid root also carries some risk: an attacker might be able to exploit vulnerabilities inbwrapto 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 
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.
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.
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