search

MinterTeam / minter-console-web

Official Minter Console website
https://console.minter.network
MIT License
35 stars 22 forks source link

Unpriveleged user namespace clone #10

Open openmindead opened 5 years ago

openmindead commented 5 years ago

Hi guys, I'd better write in English just to be clear for those who don't speak Russian, hope you don't mind.

Not sure whether it's a bug or INTENTIONAL but... There is an issue with current Minter Console Appimage which is related to security settings used by default in such distros as Arch Linux and its derivatives like Manjaro. I'm talking about unprivileged_userns_clone kernel setting which is set to zero by default in order to mitigate potential security issues. The latest Minter Console (v. 0.5.0) requires this setting to be 1 to work fine, the previous one (v. 0.4.1) has no problems with the default setting 0.

$ ./minter-console-0.5.0-x86_64_d094b8e27a6a26c34083684f238bd241.appimage
[11340:0720/224901.040160: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_minterMqJgwV/chrome-sandbox is owned by root and has mode 4755.
fish: “./minter-console-0.5.0-x86_64_d…” terminated by signal SIGTRAP (Trace or breakpoint trap)

I had a talk on this in @MinterDevChat with someone who assured me there's no such issue on his Fedora installation, I've checked on Ubuntu (it turned out they have unprivileged_userns_clone set to 1 - don't know how they both mitigate potential risks). openSUSE also has no problem in launching this version of Console (however no idea how it mitigates the risk either). So from what I can see now, Arch-based distros are affected by this. The thing is, there is no valid reason for an appimage to demand me changing my kernel configuration, especially if I am running the stock configuration of my distribution. I believe that there should be no reason to lower the security settings of the kernel as a workaround.

Snap version works fine (probably because of unprivileged_userns_apparmor_policy set to 1, but that's OK since snap applications have no access to system's root).

shrpne commented 5 years ago

Hi! Thank you for reach out to us. There was an issue with sandbox mode for Chromium in Electron 5. https://github.com/electron-userland/electron-builder/issues/3872

Looks like it was fixed in the latest electron-builder release.

I have published new console release, please check it out, the issue should be fixed: https://github.com/MinterTeam/minter-console-web/releases/tag/v0.5.1-mainnet-desktop

openmindead commented 5 years ago

Ah OK I see. 0.5.1 appimage still suffers from said electron issue, however appending --no-sandbox for this specific app looks like a more reasonable workaround (for now at least). Moreover, that's not your bug so I'm closing this for being kinda irrelevant. Thanks for the tip!

shrpne commented 4 years ago

Todo investigate opportunity to enable linux support automatically https://github.com/electron/electron/issues/17972#issuecomment-486927073 https://github.com/electron/electron/issues/17972#issuecomment-578205539 https://github.com/MichMich/MagicMirror/pull/1892#issue-365023908