Possible future requirement for `--no-sandbox` flag for Ubuntu 23.10

Development
1

Hi,

Thought I'd just share this link (warning, it's lengthy and technical): [spec] Unprivileged user namespace restrictions via AppArmor in Ubuntu 23.10 - Security - Ubuntu Community Hub

To sum it up, there's a chance that in Ubuntu 23.10+ and distributions based on them, the Chromium Sandbox might need to be disabled (or at least the userns portion of it) in the same manner it currently is on Debian in the installation script. Because these changes haven't landed yet it's difficult to test in advance, but one to keep an eye on.

Cheers
James

2 Likes
2

Ubuntu 23.10 has landed today and the feature of concern isn't turned on by default. However the latest discussion I can find would imply it still will be enabled by default as an update to 23.10 after a few weeks to gather feedback.

It can be enabled temporarily with echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns, and disabled by either using echo 0 instead or rebooting, as the above command only lasts for one boot.

Unfortunately I can't get access to a machine to test on myself.

3

I'm currently upgrading from Ubuntu 23.04, so I should be able to test soon.

4

The AppImage fails to launch when unprivileged user namespace restrictions are enabled:

zsh% ./Joplin-2.12.18.AppImage
[9100:1012/181118.197235:FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
zsh: trace trap (core dumped)  ./Joplin-2.12.18.AppImage
zsh% ./Joplin-2.12.18.AppImage --no-sandbox

It does launch when given the --no-sandbox flag.

1 Like
5

I think that the easiest fix for this will be making the change here:

An alternative would be creating an AppArmor profile for Joplin. However, this would (if I understand it correctly) cause the installer to need root privileges to install the profile...

6

In addition to needing sudo to create the AppArmor profile, you'd also need to be placing the binary in a predictable location. This location shouldn't be user-writable, or it defeats the purpose of the protection, as the user could just swap the executable.

I don't think Joplin (or any Electron package that's distributed "raw") would be able to get out of needing a proper .deb package, or using --no-sandbox.

Mind, you might be able to bypass the issue by running Joplin with sudo, since then the namespace doesn't count as unprivileged; but then you're trusting that the sandbox is properly dropping the permissions it has. It should do, and Electron should refuse to run as root unless it's capable of dropping those permissions, but still feels in poor taste to me.

In theory then you could also add the SUID bit to the AppImage via the script allowing it to run as root without prompting, but again, you'd then not want this to be user-writable, or you're giving root to anything capable of changing the contents of the file.

Edit: Alternatively, maybe adding CAP_SYS_ADMIN to the AppImage would be sufficient.

1 Like
7

As an update to this, this appears to be on track for Ubuntu 24.04 still, as per Bug #2046844 “AppArmor user namespace creation restrictions caus...” : Bugs : apparmor package : Ubuntu which is tracking package level fixes going into the Ubuntu repositories.

Ubuntu 22.04 won't offer an upgrade to 24.04 until July (alongside 24.04.1), but there could possibly be a rise in bug reports relating to this from people who have done the upgrade from a previous version of Ubuntu but haven't re-run the installation script since.

2 Likes