Joplin does not work in Ubuntu 24.04 due to apparmor issue

[archisman-panigrahi]

Operating system

Linux

Joplin version

2.11.11

Desktop version info

No response

Current behaviour

The Joplin appimage does not run in Ubuntu 24.04 due to recent changes in apparmor, which prevents all electron apps from running.

For details, see electron/electron#41066 and https://bugs.launchpad.net/apparmor/+bug/2046844

A temporary fix is described here electron/electron#41066 (comment)

There is probably nothing the Joplin developers can do until apparmor fixes it, but I still wanted to report the bug to prevent huge confusion when 24.04 is released and thousands of users start using Joplin on it.

Expected behaviour

No response

Logs

$ ./Joplin.AppImage 

[9034:0418/214224.008705:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_Joplin8u3ir2/chrome-sandbox is owned by root and has mode 4755.

[personalizedrefrigerator]

It looks like the workaround was only enabled for the 23.10 version of Ubuntu:

joplin/Joplin_install_and_update.sh

Line 214 in 1ef4e57

if [[ $DISTVER = "Ubuntu23.10" || $DISTVER =~ Debian1. || ( "$DISTVER" = "Linuxmint4" && "$DISTCODENAME" = "debbie" ) || ( "$DISTVER" = "CentOS" && "$DISTMAJOR" =~ 6|7 ) ]]; then

This line likely needs to be changed to include 23.10 and all later versions.

[jrjohansen]

unfortunately Joplin is only shipped as an appimage for Linux. Which means we can not ship a profile for it by default that will allow it to use capabilities within the unprivileged user namespace that the electron embedded browser is attempting to use.

This means that the user is required to intervene to enable an electron based appimage so that it can be run. Unfortunately for 24.04 this means some manual command line based intervention, instead of using a GUI like on MacOS when a user needs to enable an application downloaded from the internet.

If you look in the kernel logs, (or dmesg) you will find an message an apparmor message similar to below showing what is causing your issue.

$ sudo dmesg | grep "apparmor=\"AUDIT"

[   85.468352] audit: type=1400 audit(1713509122.843:224): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=3058 comm="@joplinapp-desk" requested="userns_create" target="unprivileged_userns"

and

$ sudo dmesg | grep DENIED

[   85.469966] audit: type=1400 audit(1713509122.847:225): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=3065 comm="@joplinapp-desk" capability=21  capname="sys_admin"

Unfortunately unprivileged user namespaces are using privileged kernel interfaces (above protected by capabiity sys_admin) that have now been restricted to known applications because they have been used in a lot of exploit chains.

you can add a profile for the application by copying the profile from below into /etc/apparmor.d/ and then updating by replacing /home/jj/Downloads/Joplin-2.14.20.AppImage with the location you are running your joplin appimage from.

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile joplin /home/jj/Downloads/Joplin-2.14.20.AppImage  flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/firefox>
}

Once that is done you can do

$ sudo apparmor_parser -r /etc/apparmor.d/joplin

that will allow you to run joplin without having to reboot. Having the jplin profile in /etc/apparmor.d/ will ensure it is reloaded if you reboot.

[archisman-panigrahi]

@personalizedrefrigerator Running as --no-sandbox is probably not enough. The script needs to create the apparmor profile in 24.04 (with the location of the appimage) and run the apparmor_parser command mentioned above.

[personalizedrefrigerator]

you can add a profile for the application by copying the profile from below into /etc/apparmor.d/ and then updating by replacing /home/jj/Downloads/Joplin-2.14.20.AppImage with the location you are running your joplin appimage from.

Thank you for the suggestion!

I have a few concerns about this:

• It means that the installer will require root access.
• Overwriting /home/user/path/to/Joplin-2.14.20.AppImage could give an attacker access to unprivileged user namespaces.
  • This would mean, however, that an attacker would already need to be able to write files and run code as the user with Joplin installed.
• Uninstalling Joplin becomes a bit more complicated, particularly if multiple users on a computer have Joplin installed. In this case, the AppArmor profile also needs to be removed, but only if all users have uninstalled Joplin.
  • One solution could be to use a flag --full-uninstall.
  • Another solution could be to install the AppImage to a globally-accessible location (e.g. in /usr).

See also the posts by @JGCarroll on the relevant forum discussion.

[jrjohansen]

@personalizedrefrigerator Running as --no-sandbox is probably not enough. The script needs to create the apparmor profile in 24.04 (with the location of the appimage) and run the apparmor_parser command mentioned above.

actually --no-sandbox should work as well. Ubuntu isn't going so far as requiring a profile for all downloaded applications. Only those that use unprivileged user namespaces and try to use system capabilities within the user namespace. Since --no-sandbox will stop chrome from creating the unprivileged user namespace, that should be enough to get it to work without creating a profile.

[archisman-panigrahi]

I will check if no-sandbox works and will get back.

…

On Fri, Apr 19, 2024, 9:36 AM jrjohansen ***@***.***> wrote: @personalizedrefrigerator <https://github.com/personalizedrefrigerator> Running as --no-sandbox is probably not enough. The script needs to create the apparmor profile in 24.04 (with the location of the appimage) and run the apparmor_parser command mentioned above. actually --no-sandbox should work as well. Ubuntu isn't going so far as requiring a profile for all downloaded applications. Only those that use unprivileged user namespaces and try to use system capabilities within the user namespace. Since --no-sandbox will stop chrome from creating the unprivileged user namespace, that should be enough to get it to work without creating a profile. — Reply to this email directly, view it on GitHub <#10332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXL2XBGTDYFSZV52FEWNDDY6EMWHAVCNFSM6AAAAABGOKAXEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGYYDKNBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[JGCarroll]

--no-sandbox should work, it's been tested before. It'd be ideal if Chromium/Electron had a less binary flag for it, but unfortunately that's not the case we're in. It might change in the future though, Ubuntu isn't the only one who've started restricting access to it and even Linus Torvalds himself has called it a mistake that they're stuck with.

here is probably nothing the Joplin developers can do until apparmor fixes it

I'd not honestly expect a resolution for this in the "it just runs" manner. I know Ubuntu has been working on permissions prompting for snaps like how Android/iOs have it ("Joplin is trying to access ./SSH, would you like to allow" kind of prompts), and as I casually read through Launchpad, it seems there's an apetite for making user namespaces work the same way even outside of snaps, but it'd be unlikely to get backported into 24.04 which will persist for years.

From what I've read, the Electron Flatpaks have a trick they use called Zypak that allows the Chromium sandbox to work without SETUID bits and potentially user namespaces, it could be possibly replicated in the AppImage and provide better sandboxing than nothing.

But as far as Ubuntu the project goes, they'd likely say the answer needs to be a PPA (more maintenace effort), a snap (Which already exists), or for it to be submitted to the Universe repository (which is less than ideal because the package would become stale and eventually become incompatible for syncing with the latest clients).

Even in the snap, --no-sandbox is still used, snapd itself sets up apparmor permissions and seccomp and BPF and all that stuff so that Chromium doesn't have to, only big vendors like Mozilla or Brave or etc would be allowed to use unprivileged user namespaces, even in a snap!

[archisman-panigrahi]

I confirm that ./Joplin.AppImage --no-sandbox works in 24.04.

Please proceed with adding no-sandbox for 24.04 in Joplin_install_and_update.sh

[jrjohansen]

I'd not honestly expect a resolution for this in the "it just runs" manner. I know Ubuntu has been working on permissions prompting for snaps like how Android/iOs have it ("Joplin is trying to access ./SSH, would you like to allow" kind of prompts), and as I casually read through Launchpad, it seems there's an apetite for making user namespaces work the same way even outside of snaps, but it'd be unlikely to get backported into 24.04 which will persist for years.

So make it just runs is problematic. The goal is to stop unknown code from being able to use unprivileged user namespaces to attack the kernel. There are a few ways we can get safely get the "make it just run" behavior, like shipping profiles for known applications in locations that regular userspace code can't write. Or signed code with a valid integrity hash. Both of these exist. Unfortunately we can't do that for code that a user can just down load and run from their home dir in locations that attack code code write to gain privilege. If we enabled that, attack code would just have to add a simple step to the exploit chain.

Its not that we don't want users to be able to run these applications. Its just an unfortunate reality of how unprivileged user name space exploits work.

So we need some privileged way that a user can enable new applications. Currently that is adding a profile or signed code that can be verified by the integrity architecture. With snapd there is the opportunity for a third way via prompting the user. Unfortunately atm it is experimental and not integrated with the unprivileged user namespace yet.

Like I said unfortunately the user experience in 24.04 isn't good when failure happens. The goal is to improve the experience, and that includes 24.04. On the snap side, snapd and snaps get updated separate from the base so you will see improvements there coming back to 24.04. Some of them might depend on an HWE kernel, but if needed some changes might get backported, to older kernels (this has been done for other features).

The apparmor side we are looking to looking at the possibility of bringing new versions back to older releases to better support the HWE kernels.

From what I've read, the Electron Flatpaks have a trick they use called Zypak that allows the Chromium sandbox to work without SETUID bits and potentially user namespaces, it could be possibly replicated in the AppImage and provide better sandboxing than nothing.

Zypak is interesting, and it should be possible to get it working, at least with the caveat that the launched application won't have access/need access to privileged kernel interfaces. I haven't looked into it yet, but its on the list of things to look at.

But as far as Ubuntu the project goes, they'd likely say the answer needs to be a PPA (more maintenace effort), a snap (Which already exists), or for it to be submitted to the Universe repository (which is less than ideal because the package would become stale and eventually become incompatible for syncing with the latest clients).

So from a support hat side of things that does make things easier, but we do want to make the user experience for electron and appimages. The current situation really isn't acceptable for the average user.

Even in the snap, --no-sandbox is still used, snapd itself sets up apparmor permissions and seccomp and BPF and all that stuff so that Chromium doesn't have to, only big vendors like Mozilla or Brave or etc would be allowed to use unprivileged user namespaces, even in a snap!

Its entirely possible to create a full apparmor profile for the application, that allows it to also use unprivileged user namespaces. The unconfined profile stub is just trying to make it easier for the user, and yes t is not easy enough atm. As for snapd there is a new interface that allows access to unprivileged user nameapces, and any snap can request it. The goal is not to stop applications from using them, but to stop exp