search

standardnotes / forum

Support from other community members. For 1-on-1 help, please contact help@standardnotes.com.
https://forum.standardnotes.org
198 stars 8 forks source link

Trying to Install on MX Linux #1120

Closed gplcoder closed 1 year ago

gplcoder commented 4 years ago

Hello,

I downloaded the 'AppImage' from your website, moved it to my home directory, changed permissions and upon launch, I get:

[32139:1027/150840.299002:FATAL:setuid_sandbox_host.cc(157)] 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_standaepGFE/chrome-sandbox is owned by root and has mod 4755. Trace/breakpoint trap

I then created the folder mentioned in the error message (using root) and changed the permissions. I am not sure whether 'chrome_sandbox' is a file or a folder but I created a subdirectory and also changed it's permissions.

To my horror, upon the next launch attempt, not only did this not solve the existing issue but presented another issue when the name of the top level folder changed so this fix could not possibly work.

Environment:

Dell Precision M4800 16gb RAM 600gb Intel SSD MX Linux 19.x

According to the AppImage website, Debian (MX under the covers is Debian).

Ideas? TIA

gplcoder commented 4 years ago

Update,

After snooping around the web for this issue, I came across:

sysctl kernel.unprivileged_userns_clone=1

I ran this in a root shell and your app starts.

This is not an appropriate work around as the above command is like giving root to any application on the system and, of course, defeats Chromium sandboxing.

JaspalSuri commented 4 years ago

Hi @gplcoder,

Thank you for looking into it and for your feedback! The app currently runs without being sandboxed on Linux; we hope that it's something that we can change in the future.

JaspalSuri commented 4 years ago

Here are some links to other discussions about running Standard Notes without being sandboxed. You could switch to a kernel that sandboxes all of the apps running on your OS. However, a user did some research and found out that it might not be secure to modify your existing kernel by enabling "unprivileged user namespaces". I'm currently not sure how the Liquorix Kernel sandboxes apps.

https://github.com/standardnotes/forum/issues/955 Standard-Notes-3.3.5.AppImage won't work

https://github.com/standardnotes/forum/issues/690 standard-notes-3.0.16-x86_64 runs only with --no-sandbox

https://github.com/standardnotes/forum/issues/733 Unable to install Standard Notes on Debian Buster

https://github.com/standardnotes/forum/issues/1010 [Help Wanted] Sandbox not found

Is launching with --no-sanbox safe? - /r/StandardNotes

gplcoder commented 4 years ago

@JaspalSuri,

Thanks for the update.

I have done a lot of research on this issue. It is not only Standard Notes that is affected. Basically any application based on Electron and packaged as an AppImage cannot be run under any Linux without disabling the sandbox (it may only be Debian-based distributions being affected). As several posts in the list you published point out, it is never a good thing the intentionally lessen security.

This issue is a show-stopper for me. I will not run any web app without the appropriate security (defined by Electron). Fortunately for you, this issue affects not only your product but also the product of your chief competitor (which is deployed in exactly the same way).

JaspalSuri commented 4 years ago

Hi @gplcoder,

I spoke with @johnny243 (who has used MX Linux) and it turns out that you might be able to safely sandbox Electron apps with the Liquorix Kernel! According to Johnny (lightly edited by me):

Unprivileged user namespaces is typically enabled via the kernel option kernel.unprivileged_userns_clone, but the Liquorix Kernel does not use it. 🙂

Electron apps need the SUID sandbox (specifically with the PID namespace and Network namespace). You can check to see if they're adequately supported by your kernel by opening a Chromium-based web browser and typing about:sandbox in the address bar.

image

JaspalSuri commented 4 years ago

It appears that a recent version of MX Linux (v19.2) ships with a kernel that supports namespaces! That should help make sandboxing Electron apps on your system easier than having to install another kernel. 😃

gplcoder commented 4 years ago

I don't see how namespaces will help,

I am running V19 of MX and the .2 minor version is updated automatically and the Standard Notes AppImage still fails with the same message.

Installing a independent kernel to fix one application is too heavy-handed approach and can lead to other issues with the distribution, IMHO.

It appears that only Debian (and derivatives) manifest this issue in their kernel and since no one has tested this (that I have seen), I am going to test this by installing Virtual Box under MX and then implement a series of VM's as the guest OS (one at a time). This is also a heavy-handed approach but more reasonable than an independent kernel (IMHO).

More later.

gplcoder commented 3 years ago

I started testing with SN 3.5.1. Here are the results,

JaspalSuri commented 3 years ago

Hi @gplcoder,

Thank you so much for testing all of those distros!

Just so I can be sure, can you clarify what you mean by usual failure? Are you referring to what I posted or the error that you originally reported seeing? If the latter, I think it's because the other distros don't check to see if the app is sandboxed. Debian and MX do, since MX is Debian-based, so you'd have to install it with --no-sandbox but can rely on the latest version of the kernel used by Debian to sandbox the app.

gplcoder commented 3 years ago

Hi @JaspalSuri,

By 'usual failure' I was referring to the original error that I posted in the first post of this thread. If some of the distros that I tested don't check to see if your app is sandboxed, there is no indication in the console output (I started SN from a terminal and read the console messages before the GUI started up).

I am not sure why but my Xubuntu test was successful even though all of the Debian-based distro's failed. It could be, as you say, that the distro was not checking for the sandbox.

JaspalSuri commented 3 years ago

Hello again @gplcoder, can you try running the latest AppImage to see if will allow you to run the app without the no sandbox flag? Another user reported that it currently is possible to do so, but I wanted to run it by you in case there was anything else that you think should be checked after the app runs successfully.