Electron: Biner pembantu kotak pasir SUID ditemukan, tetapi tidak dikonfigurasi dengan benar

Sayangnya, kami tidak dapat mengonfigurasi ini dengan benar secara otomatis, karena menyetel izin yang sesuai memerlukan hak akses root dan kami tidak ingin meminta kata sandi root selama npm install .

Idealnya, Arch akan mengonfigurasi dukungan kernelnya CLONE_NEWUSER dan Chromium (dan Electron) dapat menggunakan kotak pasir namespace alih-alih mengandalkan kotak pasir setuid yang lama. Aplikasi yang didistribusikan di Linux perlu memasukkan ini ke dalam proses pemasangannya. Lihat https://github.com/electron-userland/electron-installer-debian/pull/184 dan https://github.com/electron-userland/electron-installer-redhat/pull/112 misalnya.

Selama pengembangan, kita mungkin harus mencetak sesuatu pada npm install meskipun dengan instruksi jika kita mendeteksi bahwa kotak pasir namespace tidak tersedia.

Hai, terima kasih atas responsnya yang sangat cepat!

Apakah CLONE_NEWUSER yang tidak memiliki hak istimewa berasal dari CONFIG_USER_NS=y ? Jika demikian, itu seharusnya menjadi konfigurasi saat ini.

Tolong beri tahu saya jika ada yang bisa saya lakukan untuk membantu, atau jika ini adalah output yang diharapkan di Arch, saya akan dengan senang hati menutup -- Saya mengerti bahwa ada beberapa kejanggalan yang diharapkan saat menjalankan distro yang berdarah dan saya tidak keberatan menyelesaikan ini dalam PKGBUILD daripada mengharapkannya bekerja dengan sempurna langsung dari npm. Bersulang!

CONFIG_USER_NS=y mengaktifkan fitur ruang nama pengguna, tetapi fitur tersebut masih dibatasi untuk pengguna yang memiliki hak istimewa secara default. Ini menunjukkan sysctl kernel.unprivileged_userns_clone=1

Apakah ada solusi yang mungkin sementara itu sampai setiap distro linux mengaktifkan fitur-fitur itu?

@kitingChris Kotak pasir setuid ADALAH solusinya. Anda hanya perlu memastikan bahwa saat mengembangkan / merilis aplikasi elektron, skrip dev / pengemasan Anda mengatur izin helper kotak pasir dengan benar seperti yang ditautkan @nornagon di atas.

Apakah ada solusi yang mungkin sementara itu sampai setiap distro linux mengaktifkan fitur-fitur itu?

Lihat pesan aslinya:

Jika saya chown dan chmod file maka itu berfungsi dengan baik

Lihat juga di sini https://github.com/electron/electron/issues/16631#issuecomment -476082063 Jadi untuk membuat suid sandbox berfungsi, Anda pada dasarnya harus men-tweak biner chrome-sandbox dengan cara ini:

• sudo chown root chrome-sandbox
• chmod 4755 chrome-sandbox

Masalahnya lebih parah meskipun jika menjalankan paket appimage/snap, saya belum mengungkapkan solusi yang layak untuk kasus ini. Ini berfungsi jika appimage dieksekusi dengan argumen --no-sandbox , tetapi ini adalah peretasan.

@nornagon

karena menyetel izin yang sesuai memerlukan hak akses root dan kami tidak ingin meminta kata sandi root selama instalasi npm.

Mengeksekusi chmod 4755 node_modules/electron/dist/chrome-sandbox tidak memerlukan izin root dan itu sudah cukup untuk menjalankan perintah tersebut untuk membungkus aplikasi ke paket deb/pacman/etc seperti ketika paket tersebut diinstal semua file termasuk chrome-sandbox normal dimiliki oleh akar. Jadi alangkah baiknya elektron melakukan chmod 4755 node_modules/electron/dist/chrome-sandbox secara otomatis selama proses instalasi karena tidak perlu menangani kasus ini secara manual seperti yang disebutkan di sini .

CONFIG_USER_NS=y mengaktifkan fitur ruang nama pengguna, tetapi fitur tersebut masih dibatasi untuk pengguna yang memiliki hak istimewa secara default. Ini menyarankan sysctl kernel.unprivileged_userns_clone=1

Saya mengonfirmasi bahwa menjalankan sudo sysctl kernel.unprivileged_userns_clone=1 adalah solusi lain, komentar terkait.

@vladimiry saya harus terlebih dahulu chown dan kemudian chmod. Sebaliknya itu tidak berhasil.

@burningTyger Anda benar , saya baru saja mengubah pesan aslinya.

@nornagon Jika kita chmod 4755 out/Release/chrome-sandbox pada CI apakah izin itu akan dipertahankan setelah kita zip naik atau apakah kita harus membuat perubahan ini di electron-download untuk memperbaiki izin pada DL?

sama di sini adalah fonction baru yang buruk untuk apa yang perlu diubah itu ... :(

@MarshallOfSound Zip tidak mendukung izin, tetapi pada akhirnya masalahnya bukan izin chmod, melainkan pemiliknya. Helper kotak pasir setuid adalah suid _to root_, karena perlu melakukan fungsi yang hanya tersedia untuk root. Jika dimungkinkan untuk mengatur izin yang sesuai tanpa terlebih dahulu mendapatkan hak akses root, itu akan menjadi kerentanan yang sangat serius di Linux. Untungnya untuk Linux, dan sayangnya bagi kami, tidak demikian.

Berikut adalah opsi yang saya lihat:

1. Tidak mengubah apa pun di Elektron. Sarankan agar pengembang mengaktifkan CLONE_USERNS yang tidak memiliki hak istimewa pada kernel mereka untuk memungkinkan kotak pasir namespace berjalan alih-alih kotak pasir setuid.
2. Boot tanpa kotak pasir jika tidak ada metode kotak pasir yang tersedia _hanya saat mem-boot aplikasi yang belum dikemas_. Jika Electron mem-boot aplikasi yang dikemas, tolak untuk mem-boot tanpa kotak pasir.
3. Dalam semua kasus, jika tidak ada metode sandboxing yang tersedia, boot tanpa sandboxing dan cetak peringatan.
4. Nonaktifkan sandboxing secara default di Linux.

Saya condong ke arah (2). Ini akan memudahkan pengembangan tanpa mengorbankan keamanan aplikasi yang digunakan.

Saya belum yakin apa yang harus dilakukan tentang snap/flatpak, karena saya tidak terbiasa dengan cara kerja mereka. Mungkin saja mereka sudah cukup mem-sandbox aplikasi sehingga kami dapat menonaktifkan sandboxing sama sekali dalam situasi itu, seperti yang kami lakukan saat membangun Electron versi Mac App Store.

Untuk saat ini, saya lebih suka opsi pertama.

1. Boot tanpa kotak pasir jika tidak ada metode kotak pasir yang tersedia hanya saat mem-boot aplikasi yang belum dikemas. Jika Electron mem-boot aplikasi yang dikemas, tolak untuk mem-boot tanpa kotak pasir.

Skenario seperti itu entah bagaimana bisa menyesatkan. Seseorang mungkin berhasil menjalankan aplikasi yang tidak dikemas tanpa sandboxing, tetapi ada kemungkinan bahwa aplikasi yang dikemas tidak akan bekerja dengan cara yang sama dengan sandbox yang diaktifkan. Seperti, misalnya, kasus ketika Anda mengakses proses utama dari proses renderer bukan melalui antarmuka remote . Atau kasus membungkus aplikasi ke paket AppImage / Snap / Flatpak.

1. Dalam semua kasus, jika tidak ada metode sandboxing yang tersedia, boot tanpa sandboxing dan cetak peringatan.

Jadi, aplikasi terpaket yang dirancang dan dikembangkan sebagai kotak pasir dapat dijalankan tanpa kotak pasir jika tidak tersedia kotak pasir. Ini tidak terdengar bagus untukku.

1. Nonaktifkan sandboxing secara default di Linux.

Apa artinya tepatnya? Apa cara untuk mengaktifkan kotak pasir di Linux dengan cara aplikasi dimulai atau gagal jika tidak ada kotak pasir yang tersedia (situasi saat ini, kotak pasir paksa).

Saya juga suka (1), tetapi untuk mempertahankan (2) sedikit, API yang diekspos ke aplikasi tidak akan berubah saat menonaktifkan kotak pasir. Satu-satunya hal yang akan kami nonaktifkan adalah sandbox tingkat OS. Kami masih akan memuat aplikasi dengan cara yang sama, hanya saja tidak akan dilindungi oleh OS.

Kami masih akan memuat aplikasi dengan cara yang sama, hanya saja tidak akan dilindungi oleh OS.

Kemudian kedengarannya bagus juga bagi saya. Terima kasih atas penjelasannya.

Saya tidak suka 2., karena keamanan opsional umumnya menyebabkan orang menonaktifkan keamanan.

Melangkah ke sepatu "pengguna bodoh" sekarang, saya lebih suka melihat Electron bekerja secara default. Jika ini adalah tindakan keamanan yang sangat penting, beri saya peringatan dan penjelasan yang baik tentang mengapa saya perlu melakukan pekerjaan ekstra. Jika tidak begitu penting, maka jangan beri saya rasa "tidak berfungsi" yang buruk.

Karena itu, saya suka 1. (dengan paksa berhenti, seperti sekarang) atau 4.

:x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox menimbulkan beberapa tanda bahaya bagi saya.

Untuk memperjelas fungsinya: Ini menetapkan bit SUID pada chrome-sandbox , yang membuat _setiap pengguna_ dapat mengeksekusi file _as root_. Ini berarti bahwa jika ada cara untuk menggunakan chrome-sandbox jahat, atau jika konten menjadi berbahaya, pengguna mana pun dapat menjadi root. chrome-sandbox akan menjadi target yang sangat menarik untuk diserang.

Saya sangat menyarankan untuk tidak melakukan solusi ini pada npm install , karena akan membutuhkan sudo (pengguna perlu menulis kata sandi), ini invasif dan kami mungkin tidak memahami konsekuensi keamanan dari melakukannya.

chown root:root chrome-sandbox && chmod 4755 chrome-sandbox memunculkan beberapa tanda bahaya bagi saya.

Tentu saja. Tetapi Anda dapat mengaktifkan kotak pasir User Namespace sebagai alternatif sudo sysctl kernel.unprivileged_userns_clone=1 (diaktifkan secara default di Ubuntu tetapi tidak di Arch).

Untuk memperjelas fungsinya: Ini menetapkan bit SUID pada chrome-sandbox , yang membuat _setiap pengguna_ dapat mengeksekusi file _as root_. Ini berarti bahwa jika ada cara untuk menggunakan chrome-sandbox jahat, atau jika konten menjadi berbahaya, pengguna mana pun dapat menjadi root. chrome-sandbox akan menjadi target yang sangat menarik untuk diserang.

Ya, tetapi juga biner ini sama persis dengan yang disertakan dengan Chrome, jadi jika Anda khawatir tentang ini, Anda mungkin juga harus mencopot pemasangan Chrome :)

Apakah ada cara untuk menjalankan tanpa kotak pasir/berjalan tanpa "pembantu kotak pasir"? Punya pengguna pertama yang mengeluh
Saya mengharapkan ini untuk menonaktifkan kotak pasir, tetapi masih mendapatkan kesalahan The SUID sandbox helper binary was found, but is not configured correctly .
Saya akan benci untuk memutar kembali ke elektron 4.x

Pesan eror

Ulasan & suid Snapcraft

Saya mencoba mengunggah snap dengan flag suid di chrome-sandbox tetapi proses peninjauan dari snapcraft melarang penggunaan flag suid.

The store was unable to accept this snap.
  - checksums do not match. Please ensure the snap is created with either 'snapcraft pack <DIR>' (using snapcraft >= 2.38) or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs -no-fragments'. If using electron-builder, please upgrade to latest stable (>= 20.14.7). See https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/17 for details.
  - found errors in file output: unusual mode 'rwsr-xr-x' for entry './chrome-sandbox'

@thomasnordquist untuk menonaktifkan sandboxing tingkat OS --no-sandbox perlu diteruskan sebagai argumen aplikasi, yaitu app.commandLine.appendSwitch tidak akan cukup. Mengenai paket Snap, Anda mungkin ingin mencoba menambahkan steker seperti yang dijelaskan di sini . Tidak yakin apakah itu akan membantu karena saya belum mencobanya, akan lebih bagus jika Anda melakukannya. Untuk saat ini saya lebih suka merilis aplikasi yang telah saya buat dalam mode campuran : smile:. Electron v5 digunakan untuk semua paket kecuali AppImage dan Snap karena belum sepenuhnya jelas bagaimana membuat paket-paket ini bekerja dengan baik dengan sandboxing diaktifkan, tetapi akan menjadi jelas di beberapa titik.

Jika Snapcraft melarang bendera suid maka mungkin satu-satunya pilihan adalah menonaktifkan sandbox Electron sepenuhnya di Snapcraft dan mengandalkan wadah yang digunakan Snapcraft. Saya tidak yakin apa cara terbaik untuk melakukannya—apakah mungkin untuk menentukan flag baris perintah tambahan saat mengemas melalui Snapcraft? Jika demikian, kita dapat menambahkan flag --no-sandbox . Jika tidak, kami mungkin perlu menambahkan beberapa mekanisme deteksi khusus untuk mendeteksi berjalan di Snapcraft/Flatpak dan menonaktifkan sandboxing berdasarkan deteksi tersebut.

Beberapa dokumentasi terkait Snap https://docs.snapcraft.io/browser-support-interface

@posix4e dapatkah Anda menjelaskan masalah menjalankan paket Snap kotak pasir di mode User Namespace dan SUID sandbox/fallback? Sepertinya Anda memiliki pengalaman yang relevan dalam mengutak-atik konfigurasi snap dari Brave Browser. CC @flexiondotorg.

Untuk memperjelas fungsinya: Ini menetapkan bit SUID pada chrome-sandbox , yang membuat _setiap pengguna_ dapat mengeksekusi file _as root_. Ini berarti bahwa jika ada cara untuk menggunakan chrome-sandbox jahat, atau jika konten menjadi berbahaya, pengguna mana pun dapat menjadi root. chrome-sandbox akan menjadi target yang sangat menarik untuk diserang.

Ya, tetapi juga biner ini sama persis dengan yang disertakan dengan Chrome, jadi jika Anda khawatir tentang ini, Anda mungkin juga harus mencopot pemasangan Chrome :)

Saya sebagian khawatir membiarkan biner dari Chrome memiliki root:root dengan set SUID, ya. Sangat sedikit kode yang tanpa bug. Ini kode sumbernya, sebagai catatan: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Tetapi saya lebih khawatir jika npm install akan:

1. Unduh banyak perangkat lunak dengan cepat.
2. Secara otomatis membuat salah satu file root:root dan SUID.

Saya pikir itu akan menjadi tumpukan perangkat lunak pertama yang saya ketahui yang secara otomatis melakukan sudo chown root:root && sudo chmod 4755 pada file yang dimiliki oleh pengguna non-root.

Melakukan sudo chown root:root && sudo chmod 475 pada npm install seharusnya tidak mungkin, npm perlu dijalankan sebagai root untuk mengatur izin. Model kait npm akan memungkinkan semua paket yang diinstal untuk menjalankan kaitnya sebagai root juga. Dengan kemungkinan ratusan paket & dependensi bersarang, ini akan sangat berbahaya.

Melakukan sudo chown root:root && Sudo chmod 475 pada npm install seharusnya tidak mungkin

Ini tidak dianggap sebagai pilihan sejauh yang saya mengerti.

Saya setuju bahwa melakukan apa pun yang memerlukan hak akses root selama npm install adalah non-starter. Itulah sebabnya saya tidak mencantumkannya sebagai salah satu opsi .

Untuk apa nilainya, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0, dan electron-installer-snap 3.2.0 telah dirilis dengan perubahan kotak pasir SUID. Electron Forge v5 dan v6 beta juga harus diperbarui secara transitif (melalui pembaruan versi dalam jangkauan, gunakan npm update atau yarn upgrade tepat).

Hanya menautkan kode terkait untuk kejelasan.

Untuk memperjelas, untuk Snaps ada lebih dari itu (yaitu, menambahkan dukungan kotak pasir browser seperti disebutkan di atas). Lihat perubahan PR terkait untuk detailnya.

Saya baru saja menekan ini, chown / chmod berfungsi, tetapi itu bukan satu-satunya tindakan yang perlu diambil jika Anda menjalankan di dalam gambar Docker.

Jika Anda hanya melakukannya, Anda akan menerima kesalahan lain:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Cara mengatasinya adalah dengan menambahkan --privileged ke perintah docker run . Saya tidak berpikir ini adalah solusi yang baik, terutama pada CI.

@JCMais sepertinya Electron salah mencoba menggunakan kotak pasir namespace di dalam buruh pelabuhan, meskipun seharusnya mencoba menggunakan kotak pasir suid. Saya tidak yakin mengapa itu terjadi, tetapi Anda dapat memaksa kotak pasir suid dengan --disable-namespace-sandbox . Jika Anda meluncurkan buruh pelabuhan dengan --privileged (atau --cap-add SYS_ADMIN , atau profil seccomp khusus yang memungkinkan CLONE_NEWUSER), maka ruang nama akan tersedia di dalam kotak pasir dan tidak perlu kotak pasir setuid atau pembantunya dapat dieksekusi .

Seperti @thomasnordquist, saya akhirnya menonaktifkan sandboxing untuk paket Snap/AppImage menggunakan skrip preload. Anda membuat skrip sh seperti preload bernama biner asli yang kemudian digunakan untuk memuat nama baru/biner elektron asli dengan argumen --no-sandbox . Lebih mudah dilakukan dalam skrip after-pack pembuat elektron

@nornagon bagaimana tepatnya saya harus meneruskan bendera ini ke elektron? Saya mencoba menambahkan --disable-namespace-sandbox tetapi terus memberi saya kesalahan:

:~$ electron --disable-namespace-sandbox
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Dapat mengonfirmasi bahwa ini membuat saya mati seketika dan semua pengguna Linux kami terjebak pada versi lama sampai saya dapat memperbaikinya.

Saya BENAR-BENAR mencari cara untuk meningkatkan keamanan tetapi ini dikirimkan tanpa tanda fitur untuk mematikannya.

Saya juga ingin berargumen bahwa ini seharusnya tidak dikirimkan tanpa fitur untuk menonaktifkannya melalui kode. Saya kira mungkin ini tidak disengaja karena --no-sandbox tidak berfungsi kecuali diberikan secara manual dari baris perintah.

Jika ada yang salah dengan cara electron-installer-snap mengimplementasikan dukungan kotak pasir, beri tahu saya di pelacak masalah.

Jika ada yang salah dengan cara electron-installer-snap menerapkan dukungan sandbox, beri tahu saya di pelacak masalah.

Saya juga ingin mendengar seseorang mengonfirmasi bahwa perubahan itu cukup untuk mengatasi masalah dengan paket Snap. Jadi baik umpan balik positif/negatif disambut. Lihat info terkait.

@vladimiry saya melanjutkan dan mengujinya dan tidak berhasil.

Saya membutuhkan solusi yang tidak mengatasi patch OS, sysctl, atau reboot. Saya butuh sesuatu yang berfungsi sekarang. --no-sandbox akan lebih disukai.

Akan jauh lebih membantu saya jika seseorang dapat menyediakan aplikasi Electron minimal yang dapat saya gunakan untuk mereproduksi Snap paket yang tidak berfungsi. Saya menggunakan garpu electron-quick-start untuk membuat Snap di CircleCI dan menginstalnya di laptop (Debian Stretch) saya untuk memverifikasi bahwa perubahan saya setidaknya membangun aplikasi Electron yang berfungsi.

"Tidak berhasil" tidak membantu saya menunjukkan dengan tepat apa yang dapat saya lakukan di electron-installer-snap agar dapat dikemas dengan benar untuk orang lain.

@burtonator , terima kasih telah menguji barangnya. Sejauh yang saya tahu, dikemas ke dalam skrip bash/sh mirip pemuat Snap/AppImage build yang memulai biner/elektron asli dengan argumen cmd --no-sandbox adalah satu-satunya solusi yang diverifikasi untuk saat ini.

@malept sebelum menguji hal-hal yang ada kebutuhan untuk menonaktifkan fitur User Namespace OS dengan menjalankan sudo sysctl kernel.unprivileged_userns_clone=0 .

@vladimiry ya, laptop saya sudah memiliki pengaturan pengguna itu.

Jika ada orang yang mencari solusi untuk cek ini keluar @thomasnordquist 's solusi atau saya adaptasi dari itu, mereka bekerja dengan menonaktifkan sandbox di Linux.

@fabiospampinato adaptasi Anda menonaktifkan kotak pasir untuk semua jenis paket Linux tetapi setidaknya paket DEB dan Pacman bekerja dengan baik dengan kotak pasir SUID (mungkin semua paket yang tidak seperti wadah), hanya perlu mengatur bit izin SUID ke chrome-sandbox biner. Tapi jangan atur bit izin SUID untuk paket Snap karena Snap Store menolak paket semacam itu. Jadi saya menetapkan bit SUID untuk semua paket Linux mengharapkan paket Snap/AppImage yang menonaktifkan sandboxing, kode terkait .

CONFIG_USER_NS=y mengaktifkan fitur ruang nama pengguna, tetapi fitur tersebut masih dibatasi untuk pengguna yang memiliki hak istimewa secara default. Ini menyarankan sysctl kernel.unprivileged_userns_clone=1

Saya mengonfirmasi bahwa menjalankan sudo sysctl kernel.unprivileged_userns_clone=1 adalah solusi lain, komentar terkait.

Terima kasih sobat, bekerja untuk saya! @vladimiry

apakah kalian tahu jika itu berfungsi sekarang dengan 5.0.2?

@p3x-robot Tidak disebutkan masalah ini di changelog. Baru saja diperiksa untuk memastikan dan kesalahan masih ada untuk saya.

@rybaczewa terima kasih atas tanggapannya, saya tetap menggunakan v4 juga, karena ini adalah masalah besar, tidak dapat menunggu sampai v5 berfungsi, ciao

tidak bisa menunggu sampai v5 bekerja

v5 berfungsi

Agar jelas bagi orang-orang di utas ini @ p3x-robot @rybaczewa masalah ini dibiarkan terbuka untuk tujuan informasi / hilir. Elektron sendiri bekerja seperti yang diharapkan dan tidak ada yang bisa kita "perbaiki" di sini.

Jika Anda melihat pesan log ini, Anda harus menjalankan sudo sysctl kernel.unprivileged_userns_clone=1 atau memberikan biner chrome_sandbox izin yang benar seperti yang dijelaskan dalam pesan kesalahan.

@vladimiry @MarshallOfSound mengapa kau mengatakan ini adalah tetap? Di Snap, saya tidak dapat menginstal aplikasi saya P3X Redis dan P3X Onenote baik sudo sysctl kernel.unprivileged_userns_clone=1 atau memberikan chrome_sandbox v5.0.x. Saya hanya dapat menginstal dengan v4.xx

Anda pikir pengguna ingin menggunakan sudo ? Mereka akan berpikir program ini buruk dan mereka akan menghapus aplikasinya..
Versi v5 atau v6 atau v7 tidak berfungsi dengan benar, maka ini adalah bug :

Dukungan @p3x-robot snap seperti yang ditunjukkan di atas tergantung pada bagaimana Anda membuat snap. electron-installer-snap memiliki dukungan untuk ini di luar kotak dan seperti yang disebutkan di atas jika modul itu memiliki masalah / tidak berfungsi, silakan angkat masalah pada modul itu.

Silakan lihat repo electron-installer-snap untuk detailnya atau dokumen snapcraft di kotak pasir browser

Untuk mengulangi, pemahaman saya saat ini di sini adalah bahwa tidak ada bug yang harus diperbaiki, kotak pasir Electron beroperasi seperti yang diharapkan. Apa yang sedang dibahas di sini adalah masalah yang dihadapi orang dengan mengemas biner chrome_sandbox

ini aneh, karena saya sudah menambahkan kotak pasir:

app.enableSandbox()
app.commandLine.appendSwitch('no-sandbox')

keluaran:

patrikx3<strong i="9">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ /snap/bin/p3x-redis-ui 
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
[12999:0525/085646.618618: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 /snap/p3x-redis-ui/5/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)
patrikx3<strong i="10">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ 

Saya mencoba ini sebagai: app.enableSandbox() , tetapi saya mendapatkan:

Uncaught ReferenceError: require is not defined
    at onload.js:1

Jika saya menghapus garis, itu berfungsi.

@MarshallOfSound saya menggunakan electron-builder

untuk Anda semua, jika Anda ingin membuatnya berfungsi, saya membuat pembantu:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
jika Anda menggunakan electron-builder , Anda menambahkannya seperti ini:

untuk Anda semua, jika Anda ingin membuatnya berfungsi, saya membuat pembantu:

Solusi seperti itu telah berkali-kali disebutkan dalam diskusi masalah ini, inilah mengapa saya menulis sebelumnya bahwa elektron v5 berfungsi.

@vladimiry terima kasih, saya melewatkan solusi ini, saya baru saja menambahkan solusi asli javascript alih-alih TypeScript ...

satu-satunya masalah adalah ketika saya melakukan ini setelah paket hack, itu tidak menggunakan pada panel ikon dari elektron, tetapi menghasilkan ikon ke-2, bagaimana cara mengatasinya? Saya pikir itu adalah bendera tanpa kotak pasir yang melakukannya. siapa pun?

itu hanya terjadi dengan --no-sandbox :

@fabiospampinato adaptasi Anda menonaktifkan kotak pasir untuk semua jenis paket Linux tetapi setidaknya paket DEB dan Pacman bekerja dengan baik dengan kotak pasir SUID (mungkin semua paket yang tidak seperti wadah), hanya perlu mengatur bit izin SUID ke chrome-sandbox biner. Tapi jangan atur bit izin SUID untuk paket Snap karena Snap Store menolak paket semacam itu. Jadi saya menetapkan bit SUID untuk semua paket Linux mengharapkan paket Snap/AppImage yang menonaktifkan sandboxing, kode terkait .

apakah kalian tahu bagaimana saya bisa menyimpan satu ikon, bukan dua?

https://github.com/electron-userland/electron-builder/issues/3872

https://github.com/patrikx3/onenote/issues/65

@p3x-robot ada cara untuk menambahkan argumen --no-sandbox ke aplikasi wadah Snap yang dikemas tanpa memperkenalkan skrip bash/sh seperti preloader:

• Buka paket snap terlebih dahulu dengan menjalankan unsquashfs your-snap-file.snap .
• Edit ./squashfs-root/command.sh dengan menambahkan argumen yang diperlukan di sana.
• Kemas folder ./squashfs-root kembali ke paket snap dengan menjalankan perintah snapcraft pack ./squashfs-root .

Saya tidak mencoba tetapi saya pikir tindakan pengemasan ulang yang serupa dapat diterapkan ke paket AppImage juga, yaitu soal menjalankan perintah unpack/pack yang berbeda.

Saya kira tindakan pengemasan ulang yang dijelaskan dapat dipicu di kait pembuat elektron afterAllArtifactBuild .

@vladimiry terima kasih banyak, untuk yang menarik untuk afterAllArtifactBuild, saya akan mencoba mengubah command.sh tanpa membongkar, tetapi untuk besok, terima kasih lagi!

yang menarik untuk afterAllArtifactBuild

@p3x-robot afterAllArtifactBuild hook sebenarnya tidak dipicu seperti yang saya harapkan, tetapi cukup mudah untuk memicu Snap atau pembuatan tipe paket lainnya secara terprogram. Lihat di sini contoh kode. snapFile adalah file hasil di sini, jadi Anda dapat membongkar/ unsquashfs kemudian, menerapkan perubahan yang diperlukan dan mengemas kembali/ snapcraft pack . Dalam kode contoh saya mengemas kamus Hunspell ke dalam folder ./usr/share/hunspell Snap.

@vladimiry saya hanya menggunakan Electron v4, karena itu berfungsi. Saya pikir seseorang akan memperbaiki ini.

@ p3x-robot Saya masih cenderung berpikir bahwa Anda harus mengakui bahwa tidak ada yang perlu diperbaiki.

@vladimiry tidak ada yang perlu diperbaiki, tentu. :)

adakah yang tahu jika Electron v5.0.2 bekerja dengan masalah kotak pasir?

Ini sama dengan v.5.0.0 :smile:

Saya harap ini tidak keluar dari topik tetapi untuk AppImages di Debian (9) saya mendapatkan kesalahan:

The setuid sandbox is not running as root. 

Perbaiki saya jika saya salah tetapi saya mengerti (terutama dari diskusi ini) bahwa ini disebabkan oleh fitur ruang nama pengguna yang dinonaktifkan yang

Jadi mengenai saran ini:

1. Tidak mengubah apa pun di Elektron. Sarankan agar pengembang mengaktifkan CLONE_USERNS yang tidak memiliki hak istimewa pada kernel mereka untuk memungkinkan kotak pasir namespace berjalan alih-alih kotak pasir setuid.

Saya ingin menampilkan pesan kepada pengguna yang mengatakan bahwa itu hanya berfungsi ketika fitur ruang nama pengguna diaktifkan (mungkin dengan petunjuk tentang cara melakukannya) dan menyarankan untuk menggunakan paket .deb sebagai alternatif.

Bagaimana saya bisa menerapkan pesan seperti itu sebelum kesalahan ditampilkan? Apakah ada cara untuk menambahkan skrip khusus ke AppRun dari AppImage tanpa membongkar dan mengemas ulang?

Apakah ada cara untuk menambahkan skrip khusus ke AppRun dari AppImage tanpa membongkar dan mengemas ulang?

@gcascio ada pesan di utas tentang penggunaan skrip sh seperti pemuat yang dapat disuntikkan oleh skrip afterpack .

Terima kasih untuk balasan Anda. Tapi saya pikir AppRun yang dihasilkan tidak tersedia ketika afterpack dipanggil atau saya salah, setidaknya saya tidak dapat menemukannya di appOutDir ?

Saya pikir AppRun yang dihasilkan tidak tersedia saat afterpack dipanggil

Saya menulis tentang menggunakan skrip sh seperti pemuat tetapi bukan tentang menambal skrip AppRun. Jika Anda ingin menambal skrip AppRun, sepertinya tidak ada cara untuk melakukannya tanpa pengemasan ulang.

Oke benar saya salah paham. Saya mungkin akan pergi dengan pengemasan ulang lalu terima kasih.

Saya mungkin akan pergi dengan pengemasan ulang lalu terima kasih.

@gcascio jika Anda memerlukan template .

ia sama dengan kesalahan "Binary pembantu kotak pasir SUID ditemukan" tetapi pada file snap setelah menginstal
bagaimana bisa memperbaikinya?

@vladimiry Saya bekerja di Docker IDE online bernama http://gitpod.io menjalankan wadah Debian. Saya tidak dapat memperbaiki masalah chrome-sandbox karena saya tidak memiliki akses Sudo. Nada umum di sini adalah bahwa ini adalah masalah Chrome dan bukan masalah Elektron, tetapi Jika Electron dapat menyelesaikan masalah, bukankah itu hal yang baik?

Dari situs ini https://www.gitpod.io/blog/gitpodify/ Saya telah melihat solusi untuk menggunakan Dalang dalam wadah.

const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});

Bisakah Electron mencoba beberapa kode seperti itu jika kesalahan kotak pasir terjadi, sebelum mematikan proses? Atau apakah ini sesuatu yang bisa saya panggil dengan file bash?

Bisakah Electron mencoba beberapa kode seperti itu jika kesalahan kotak pasir terjadi, sebelum mematikan proses? Atau apakah ini sesuatu yang bisa saya panggil dengan file bash?

Ya, meneruskan argumen --no-sandbox ke biner aplikasi elektron secara umum seharusnya mengatasi masalah ini.

Bergantung pada paket instalasi, Anda dapat menyetel bit izin SUID (4755) ke biner chrome-sandbox (untuk paket seperti deb, pacman, dll.) atau hardcode argumen --no-sandbox ke skrip sh/bash loader (untuk paket seperti Snap dan AppImage). Inilah yang saat ini saya lakukan sehingga tidak perlu melakukan apa pun untuk pengguna aplikasi (tidak diperlukan akses Sudo).

Rilis pembuat elektron baru --no-sandbox tetapi hanya untuk paket Snap.

Terima kasih @vladimiry electron --no-sandbox sepertinya bisa mengatasi masalah ini. Saya juga akan checkout SNAP.

ada pembangun elektron yang lebih baru, tetapi AppImage masih belum diperbaiki, benar?

apakah elektron 6 memperbaiki kesalahan kotak pasir? saya masih menggunakan v4 karena saya tidak dapat memperbaikinya, baik 5 atau 6.

Inilah situasinya:

• Electron v5 mengaktifkan mode campuran sandbox (yaitu beberapa proses di-sandbox dan lainnya tidak) di Linux. Ini tidak mengubah apakah proses perender Anda dikotak pasir secara default, tetapi ini berarti bahwa proses GPU sekarang dikotak pasir.
• Kotak pasir Chromium di Linux menggunakan fitur OS yang disebut CLONE_NEWUSER . Beberapa kernel dibuat dengan fitur ini yang dibatasi untuk pengguna yang memiliki hak istimewa karena sangat berhati-hati. Anda dapat membaca lebih lanjut di sini [lwn, 2016].
• Saat CLONE_NEWUSER tidak tersedia, Chromium kembali menggunakan mekanisme kotak pasir berbeda yang memerlukan biner pembantu yang disetel untuk di-root. Jika biner ini tidak ada atau tidak memiliki izin yang tepat ( 4755 _dan dimiliki oleh root_), kotak pasir akan gagal untuk boot.
• Mengatur hak akses biner pembantu harus dilakukan oleh pengguna yang memiliki hak istimewa (yaitu root). Kami tidak menetapkan izin ini pada npm install , karena kami tidak ingin meminta akses root selama npm install .
• Paket rilis Electron v5 menyertakan biner pembantu, tetapi tergantung pada berbagai alat pengemasan dan distribusi untuk memastikannya mendapatkan izin dan kepemilikan yang tepat.

Ada dua solusi:

1. Aktifkan akses unprivileged ke CLONE_NEWUSER di kernel Anda. Beberapa kernel mendukung perubahan ini dengan sysctl kernel.unprivileged_userns_clone=1 .
2. Nonaktifkan sandboxing sepenuhnya dengan meluncurkan --no-sandbox . Menambahkan argumen ini dari JS sayangnya tidak cukup, karena proses GPU diluncurkan sebelum proses utama JS dijalankan.

Kami tidak akan mendukung penonaktifan sandbox di Electron secara otomatis ketika kondisi ini terdeteksi. Anda harus memastikan bahwa paket Anda didistribusikan untuk mengatur izin yang sesuai. Sebagian besar alat (setidaknya pembangun elektron, penginstal elektron, debian penginstal elektron, dan penginstal elektron redhat) mendukung ini secara otomatis dan tidak memerlukan konfigurasi dari pengembang. Jika Anda menggunakan alat lain yang tidak mendukung ini, ajukan masalah pada alat itu dan tautkan ke komentar ini.

Saya menutup masalah ini karena, seperti yang disebutkan dalam paragraf sebelumnya, kami tidak akan mengubah persyaratan bahwa Electron dalam produksi memerlukan akses ke kotak pasir yang berfungsi kecuali jika diinstruksikan sebaliknya. Namun, untuk memudahkan pengembangan, saya telah membuka #19550 untuk melacak opsi penurunan otomatis ke mode non-sandbox ketika Electron diinstal melalui npm install , daripada melalui paket terdistribusi.

@p3x-robot Anda dapat menemukan contoh minimal untuk solusi 2. disebutkan oleh @nornagon di sini yang terinspirasi oleh @vladimiry

@gcascio tapi saya bisa menghapus snap hack kan? saat jepretan dikerjakan di pembuat elektron, dapatkah Anda mengonfirmasi?

@gcascio berhasil, terima kasih banyak! berhasil!

@gcascio tidak bekerja, ini menghasilkan 2 ikon, jadi saya kembali ke elektron v4.2.8... :(

@p3x-robot terima kasih atas umpan baliknya. Jika Anda tertarik, saya telah membuat masalah dan akan menyelidiki segera setelah saya menemukan waktu.

@nornagon sehingga kami bahkan tidak dapat menjalankan Electron 6 di Debian dan tidak mungkin kami memberikan izin root proses chrome. Solusi yang diberikan tidak cukup dari perspektif pengguna.

Ada dua solusi:
Aktifkan akses tanpa hak ke CLONE_NEWUSER di kernel Anda. Beberapa kernel mendukung perubahan ini dengan sysctl kernel.unprivileged_userns_clone=1.

Sama sekali tidak ada cara bermain-main dengan komputer pelanggan adalah cara untuk melakukannya.

Nonaktifkan sandboxing sepenuhnya dengan meluncurkan dengan --no-sandbox. Menambahkan argumen ini dari JS sayangnya tidak cukup, karena proses GPU diluncurkan sebelum proses utama JS dijalankan.

Bagaimana kalau menambahkan tanda --sandbox dan mematikan fitur kotak pasir secara default? Ini memiliki manfaat tidak mengacaukan 99% orang yang menggunakan Electron.

Solusi yang diberikan tidak cukup dari perspektif pengguna.

Menggunakan skrip/program seperti pemuat yang akan menambahkan --no-sandbox arg juga dapat dianggap sebagai solusi, jadi tidak diperlukan tindakan pengguna akhir. Selain itu, loader tersebut dapat menguji dukungan user namespace terlebih dahulu dan menambahkan --no-sandbox hanya jika diperlukan.

@pronebird memberikan root setuid biner chrome-sandbox jauh lebih berbahaya daripada menjalankan Electron tanpa sandbox. Pertimbangkan: _Anda_ orang yang mengirimkan binari Electron, sehingga Anda dapat merasa yakin bahwa Anda mengirimkan kode tepercaya (misalnya dengan menandatanganinya). Namun, jika aplikasi Anda dapat diyakinkan untuk memuat kode yang tidak tepercaya (mungkin dengan sengaja, misalnya dengan menavigasi ke URL di web), maka aplikasi akan dengan senang hati mengeksekusi kode tersebut dengan izin pengguna, tanpa kotak pasir apa pun. Saya akan jauh lebih peduli tentang pertahanan terhadap serangan yang berfokus pada menjalankan JS yang tidak tepercaya dalam proses tanpa kotak pasir di aplikasi Anda daripada tentang serangan yang melibatkan eksploitasi bug di sistem kotak pasir yang sama yang digunakan Chrome. (Dan saya berharap yang terakhir untuk diperbaiki _sangat cepat_ jika ditemukan.) Jika Anda ingin mengaudit sendiri kode biner chrome-sandbox , Anda dapat memulai di sini: https://chromium.googlesource. com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424

Jika Anda berkomitmen untuk menjalankan tanpa kotak pasir Electron, saya sangat menyarankan kotak pasir dengan cara lain, misalnya snapcraft atau flatpak, pembuat paket yang menurut saya menyertakan skrip peluncur yang menonaktifkan kotak pasir Electron di dalam wadah.

@nornagon

memberikan root setuid biner chrome-sandbox jauh lebih berbahaya daripada menjalankan Electron tanpa sandbox. Pertimbangkan: Andalah yang mengirimkan binari Electron, sehingga Anda dapat merasa yakin bahwa Anda mengirimkan kode tepercaya (misalnya dengan menandatanganinya). Namun, jika aplikasi Anda dapat diyakinkan untuk memuat kode yang tidak tepercaya (mungkin dengan sengaja, misalnya dengan menavigasi ke URL di web), maka aplikasi akan dengan senang hati mengeksekusi kode tersebut dengan izin pengguna, tanpa kotak pasir apa pun. Saya akan jauh lebih peduli tentang pertahanan terhadap serangan yang berfokus pada menjalankan JS yang tidak tepercaya dalam proses tanpa kotak pasir di aplikasi Anda daripada tentang serangan yang melibatkan eksploitasi bug di sistem kotak pasir yang sama yang digunakan Chrome. (Dan saya berharap yang terakhir akan diperbaiki dengan sangat cepat jika ditemukan.)

Tentu, tetapi menjalankan kotak pasir tidak masuk akal jika Anda memiliki aplikasi yang tidak pernah memuat konten jarak jauh apa pun. Saya percaya itu harus terjadi pada Electron – untuk membangun aplikasi desktop menggunakan tumpukan web, mungkin memuat JSON dari web, tetapi tidak seperti hanya menampilkan halaman web seperti kami tidak memiliki Safari untuk itu. Kita sudah melewati masa ketika orang biasa membungkus situs web di celah telepon, bukan?

Saya pikir overhead terlalu banyak. Saya telah menambahkan skrip bootstrap hari ini ke dalam aplikasi kami, dan menghapus biner chrome-sandbox dari distribusi, yang merupakan 5 MB lainnya. Sayangnya electron-builder tidak mendukung semua ini, jadi kami harus menambahkan pengait dan melakukannya sendiri .

Jika Anda ingin mengaudit sendiri kode biner chrome-sandbox, Anda dapat mulai di sini: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. c#424

Terima kasih. Itu benar-benar tergantung pada model ancaman, dan tidak mungkin kami menjalankan Google apa pun dengan izin root.

Ini bisa sepenuhnya aman, tetapi juga akan sangat sulit untuk memverifikasi bahwa semua sumber utuh karena pembuatan elektron dikirim melalui npm. Kami harus menyiapkan server pembuatan khusus untuk Electron dan mengaudit sumbernya sendiri. Ini akan menjadi upaya yang luar biasa dan saya lebih suka menghindarinya.

@pronebird Saya tidak akan terlalu terlibat dalam diskusi kotak pasir tetapi pendirian saya di sini adalah kita harus mengaktifkan kotak pasir secara default seperti yang kita lakukan saat ini.

Itu bisa sepenuhnya aman, tetapi juga akan sangat sulit untuk memverifikasi bahwa semua sumber utuh karena pembuatan elektron dikirim melalui npm

Ini pada dasarnya tidak benar, pembuatan elektron tidak dikirimkan melalui npm. Paket electron pada npm sebenarnya berisi sekitar 2 file dan ~40 baris JS. Build Electron yang sebenarnya dikirimkan melalui S3 dan memiliki checksum juga di S3 sehingga orang-orang dapat memvalidasi bahwa build yang mereka unduh sebenarnya adalah build yang dikirim oleh Electron.

@MarshallOfSound

Ini pada dasarnya tidak benar, pembuatan elektron tidak dikirimkan melalui npm. Paket elektron pada npm sebenarnya sekitar 2 file dan ~40 baris JS. Build Electron yang sebenarnya dikirimkan melalui S3 dan memiliki checksum juga di S3 sehingga orang-orang dapat memvalidasi bahwa build yang mereka unduh sebenarnya adalah build yang dikirim oleh Electron.

Yang saya maksud adalah, build diunduh selama tahap npm install . Saya tidak bermaksud bahwa mereka di-host secara fisik di npm. Biarlah mereka di-host di S3. Buktikan saya salah, tapi saya yakin checksum di-host di S3 yang sama, yang menurunkan tingkat keamanan sistem tersebut, hanya satu kaki. Tapi bukan itu intinya. Bayangkan skenario di mana bangunan Anda dirusak dan checksum diperbarui sesuai dengan itu. Sekarang kita punya masalah. Itu hanya risiko dan kontrol kerusakan di pihak saya. Tidak ada root = risiko lebih rendah dari sesuatu yang sangat buruk terjadi.

@pronebird chrome-sandbox biner pasti tidak boleh 5MB, itu bug. Dibuka #20049 untuk memperbaikinya, terima kasih telah menunjukkannya.

Anda tentu dapat memilih untuk menonaktifkan kotak pasir untuk kasus penggunaan Anda. Sangat disayangkan bahwa arsitektur Chromium membuatnya sehingga Anda harus meneruskan --no-sandbox pada baris perintah secara langsung daripada memanggil app.commandLine.appendSwitch ; idealnya menonaktifkan kotak pasir dimungkinkan tanpa memerlukan skrip pembungkus. Mudah-mudahan dengan #20049 kekhawatiran menghapus biner akan diperbaiki, karena ekstra 200KB jauh lebih masuk akal untuk digunakan daripada 5MB.

Apakah ada opsi untuk menggunakan sistem biner? Saya memiliki keraguan tentang memberikan bit root suid ke apa pun di folder node_modules/ saya. Terima kasih.

@gardner Anda dapat melewati --no-sandbox arg yang merupakan solusi mudah ketika Anda berada dalam mode dev.

VSCode baru saja beralih ke Electron 6 dan sekarang kami mendapatkan laporan bahwa VSCode tidak lagi dimulai kecuali opsi --no-sandbox disediakan. Apa jalan ke depan di sini? Referensi: https://github.com/microsoft/vscode/issues/81056

snap berfungsi sekarang di luar kotak, untuk appimage, ada kode tertulis yang sulit:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

selebihnya saya tidak tahu, saya hanya merilis NPM, AppImage dan SNAP...

pada dasarnya, Anda harus mengemas ulang setiap jenis item untuk menambahkan argumen ( --no-sandbox ) ke skrip peluncur.

tidak ada solusi pada Electron 6 Saya kira, Anda harus menulisnya berdasarkan paket Anda atau menunggu perbaikan atau penurunan versi ...

Untuk pengalaman pengembang yang lebih baik. Kita dapat mengatur perintah seperti di bawah ini dalam alat cli elektron.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Perintah seperti electron --ConfigSandbox.
Pengguna akan sadar dan kotak pasir dapat dengan mudah dikonfigurasi.
Dan bahkan saat pertama kali dijalankan. Kita bisa bertanya kepada mereka apakah mereka ingin mengambil tindakan. y atau n. Dan kemudian yang perlu mereka lakukan hanyalah memasukkan kata sandi. Dengan cara itu akan dilakukan dalam sekejap. Dan itu akan mengarah pada pengalaman pengguna yang besar dan menang tepat waktu. Karena Anda akan mempercayai vendor atau komunitas. Dan pergi dengan itu. Di tempat mencari di seluruh internet. Dan itu bahkan lebih berharga bagi kami yang lebih pemula. Dan itu bagus dalam semua kasus.

Masalah ini telah ditutup tetapi saya masih memilikinya dengan elektron 7.0.0 . Apakah ada komit yang menghasilkan perbaikan?

Mengapa masalah telah ditutup? Tampaknya tidak ada perbaikan yang tersedia karena masih ada bahkan di v7.0.0

Karena ini masalah pengemasan aplikasi Anda tetapi bukan masalah Electron.

Ah, baiklah. Tapi bagaimana cara memperbaikinya? Apakah ada cara di mana pengguna akhir tidak perlu melakukan pekerjaan tambahan?

Apakah ada cara di mana pengguna akhir tidak perlu melakukan pekerjaan tambahan?

Ya, ada caranya, sudah pernah dibahas sebelumnya.

sudo sysctl kernel.unprivileged_userns_clone=1

Ada masalah dengan pengguna WSL (ada banyak yang menggunakan WSL) dan WSL 1 tidak menggunakan kernel linux yang sebenarnya... kita harus menunggu rilis WSL2.

Untuk referensi mengenai batasan ini: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS=y mengaktifkan fitur ruang nama pengguna, tetapi fitur tersebut masih dibatasi untuk pengguna yang memiliki hak istimewa secara default. Ini menyarankan sysctl kernel.unprivileged_userns_clone=1

Saya mengonfirmasi bahwa menjalankan sudo sysctl kernel.unprivileged_userns_clone=1 adalah solusi lain, komentar terkait.

Ya saya menggunakan manjaro dan i3wm, saya mengambil kesalahan yang sama tetapi dengan ini berfungsi.

Apakah saya melewatkan sesuatu, atau tidak mungkin lagi mengunduh dan menjalankan aplikasi Electron tanpa akses root? Maaf, saya tidak menyadari ini khusus untuk Debian, dan bahwa kernel arus utama bahkan tidak mendukung penonaktifan ruang nama yang tidak memiliki hak istimewa.

Maafkan keberanian saya, tapi ini benar-benar gila. Electron mengekspos Node.js API bahkan dalam proses renderer. Menggunakan/mengaktifkan kotak pasir Chromium di aplikasi Electron sama sekali tidak ada gunanya, dan seperti yang Anda semua lihat dari laporan bug di sekitar GitHub yang menunjukkan masalah ini, itu juga sangat kontraproduktif. Harap nonaktifkan jika memungkinkan.

Electron mengekspos Node.js API bahkan dalam proses renderer.

Opsi nodeIntegration dinonaktifkan secara default sejak v5.

Maaf, saya tidak menyadari ini khusus untuk Debian, dan bahwa kernel arus utama bahkan tidak mendukung penonaktifan ruang nama yang tidak memiliki hak istimewa.

Jadi menjalankan debian, sepertinya saya beruntung memiliki akses root di mesin saya. Tetapi apakah saya benar bahwa fitur ini akan mencegah pengguna menjalankan aplikasi elektron (seperti AppImage atau tidak) tanpa

a) memiliki sudo , atau
b) dapat meyakinkan seseorang yang memiliki sudo untuk mengaktifkan ruang nama yang tidak memiliki hak istimewa?

@black-puppydog yah, jika mereka membuat aplikasi dari sumber, mereka dapat mengedit skrip awal untuk meneruskan argumen --no-sandbox ke elektron. Seharusnya dimungkinkan untuk memodifikasi AppImage dengan efek yang sama (dengan membongkar dan mengemasnya kembali), tetapi saya sendiri belum mencobanya. Juga bukan tidak mungkin bahwa beberapa pembuat AppImage akan menyertakan tanda itu di dalam build mereka, dalam hal ini gambar-gambar tertentu hanya akan berfungsi.

Jika tidak, saya pikir Anda benar. Perhatikan bahwa kernel jalur utama selalu mengaktifkan ruang nama yang tidak memiliki hak istimewa, dan tidak menyediakan cara untuk menonaktifkannya. Oleh karena itu mengapa ini hanya menjadi masalah di Debian.

@black-puppydog Seingat saya, penginstal meminta kata sandi root saat Anda pertama kali menginstal Debian di mesin Anda. Tapi ya, pada Debian (atau sistem lain yang menggunakan patch kernel Debian), Anda harus memiliki akses root (melalui sudo atau lainnya), atau menjalankan aplikasi Electron dengan --no-sandbox .

@ndorf Di Linux arus utama, ruang nama pengguna dapat dinonaktifkan dengan tidak mengkompilasi fitur tersebut, tetapi mereka tidak dapat diaktifkan/dinonaktifkan pada saat dijalankan atau dibatasi hanya untuk proses yang memiliki hak istimewa. Debian menambal kernelnya sedemikian rupa sehingga ruang nama pengguna dibatasi untuk proses istimewa secara default, tetapi dapat diaktifkan untuk semua proses dengan pengaturan di bawah /proc/sys .

Alasan Debian membatasinya adalah bahwa ruang nama pengguna yang tidak memiliki hak adalah risiko keamanan yang serius dengan sejarah panjang kerentanan. Ruang nama pengguna yang tidak memiliki hak memungkinkan proses yang tidak memiliki hak mengakses ke banyak fungsi kernel (UID 0, kemampuan, memasang sistem file, membuat inode perangkat, dll) yang dibatasi untuk proses yang memiliki hak istimewa hanya untuk waktu yang sangat lama. Setiap kode kernel yang mengandalkan asumsi bahwa proses yang tidak memiliki hak tidak akan pernah dapat melakukan hal-hal ini sekarang menjadi rentan karena proses yang tidak memiliki hak tiba - tiba dapat melakukan hal-hal ini.

Apakah ada solusi yang mungkin sementara itu sampai setiap distro linux mengaktifkan fitur-fitur itu?

Lihat pesan aslinya:

Jika saya chown dan chmod file maka itu berfungsi dengan baik

Lihat juga di sini #16631 (komentar) Jadi untuk membuat suid sandbox berfungsi, pada dasarnya Anda harus men-tweak biner chrome-sandbox dengan cara ini:

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

Masalahnya lebih parah meskipun jika menjalankan paket appimage/snap, saya belum mengungkapkan solusi yang layak untuk kasus ini. Ini berfungsi jika appimage dieksekusi dengan argumen --no-sandbox , tetapi ini adalah peretasan.

Ini berfungsi jika saya menjalankan aplikasi dari direktori yang tidak dikemas. Bagaimana cara mengemas direktori ini setelah mengubah izin chrome-sandbox ?

@shrinidhi111 4755 dapat dipertahankan saat dikemas, setidaknya dalam kasus paket pacman/deb. Paket juga dapat di-tweak pada level dist tertentu, mis . Adapun pemilik root, biasanya ketika paket diinstal dari repo di Linux, file terkait mendapatkan pemilik root. Dalam hal pembuatan AppImage, saya mengemasnya kembali dan hardcode --no-sandbox arg di skrip AppRun bagian dalam karena pembuat elektron belum melakukannya di luar kotak. Paket Snap dibentuk oleh pembuat elektron dengan arg --no-sandbox hardcoded (perbaikan terkait ditambahkan ~6 bulan yang lalu).

@shrinidhi111 4755 dapat dipertahankan saat dikemas, setidaknya dalam kasus paket pacman/dev. Paket juga dapat di-tweak pada level dist tertentu, mis . Adapun pemilik root, biasanya ketika paket diinstal dari repo di Linux, file terkait mendapatkan pemilik root. Dalam hal pembuatan AppImage, saya mengemasnya kembali dan hardcode --no-sandbox arg di skrip AppRun bagian dalam karena pembuat elektron belum melakukannya di luar kotak. Paket Snap dibentuk oleh pembuat elektron dengan arg --no-sandbox hardcoded (perbaikan terkait ditambahkan ~6 bulan yang lalu).

Membuat file snap adalah ide yang bagus dan menyelamatkan saya dari banyak pekerjaan. Terima kasih lagi!

bagaimana ini masih belum terselesaikan

pada snap sudah diperbaiki, saya memiliki build saya sendiri yang berfungsi dengan appimage. untuk sisanya belum terselesaikan.

Utas ini sangat panjang dan kesalahan masih ditemukan. Apakah ada ringkasan situasi di mana saja? Mungkin ringkasan seperti itu dapat ditautkan dari kesalahan.

Kedengarannya seperti https://github.com/electron/electron/issues/17972#issuecomment -495767027 dan sejenisnya mengusulkan bahwa cukup untuk memiliki fungsi elektron dengan mudah dan aman hanya pada sistem dengan akses root. Mungkin akan lebih baik jika sistem mendeteksi pengaturan izin yang salah dan menawarkan peringatan kepada pengembang, untuk mengurangi pengguna yang mengalami masalah ini, tetapi mungkin itu adalah masalah terpisah. Tampaknya juga akan lebih baik jika ada jalur bagi pengguna tanpa akses root untuk menggunakan elektron dengan mudah, dengan pemahaman yang menonjol bahwa sumber daya yang tidak dipercaya lebih berbahaya dari biasanya.

jalur untuk pengguna tanpa akses root untuk menggunakan elektron dengan mudah

--no-sandbox argumen CLI.

vladimiry, saya memikirkan misalnya pengguna akhir tanpa banyak pengalaman terminal, atau menjalankan aplikasi yang membungkus elektron

Saya sedang memikirkan misalnya pengguna akhir tanpa banyak pengalaman terminal, atau menjalankan aplikasi yang membungkus elektron

Sematkan --no-sandbox ke pintasan aplikasi. Semua paket Linux di sini akan bekerja dengan baik terlepas dari nilai sistem kernel.unprivileged_userns_clone . Jadi ini masalah pengemasan aplikasi.

Itu benar jika saya seorang pengembang, dan membuat peringatan yang sesuai untuk pengguna akhir saya. Tidakkah banyak pengembang tidak akan pernah mengetahui masalah ini karena kotak pasir namespace berfungsi untuk mereka? Juga mengkhawatirkan bahwa solusi yang ada diterapkan tanpa mengkomunikasikan kepada orang-orang yang terlibat bahwa sumber daya yang tidak tepercaya lebih berbahaya.

Solusi ini hanya berfungsi ketika Anda mendapatkan kesalahan ini karena WSL

Saya mengalami masalah ini ketika mencoba menggunakan electron di WSL (WSL2 dalam kasus saya).
Bahkan dengan menggunakan server X11, elektron tidak dapat melewati X11.

Saya harus membangun elektron untuk Windows, bahkan jika saya menjalankannya di dalam WSL. Setelah itu, semuanya berfungsi seperti yang dikecualikan
Cara paling sederhana untuk melakukannya:

• Copot pemasangan elektron npm uninstall electron
• Ubah platform konfigurasi npm export npm_config_platform=win32
• Pasang elektron npm install electron
• Hapus variabel lingkungan unset npm_config_platform

Ini menunjukkan sysctl kernel.unprivileged_userns_clone=1

Saya melihat masalah ini dengan WSL (Windows 10), Ubuntu 18.04 diinstal ke WSL.
sudo sysctl kernel.unprivileged_userns_clone=1 tidak berfungsi.

sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

Menggunakan chown dan chmod juga bukan pilihan.

@MarshallOfSound Zip tidak mendukung izin, tetapi pada akhirnya masalahnya bukan izin chmod, melainkan pemiliknya. Helper kotak pasir setuid adalah suid _to root_, karena perlu melakukan fungsi yang hanya tersedia untuk root. Jika dimungkinkan untuk mengatur izin yang sesuai tanpa terlebih dahulu mendapatkan hak akses root, itu akan menjadi kerentanan yang sangat serius di Linux. Untungnya untuk Linux, dan sayangnya bagi kami, tidak demikian.

zip _does_ mendukung izin pada sistem berbasis unix (atau setidaknya pada varian linux yang telah saya uji). Lihat https://serverfault.com/a/585889/17620

Bit izin disimpan di akhiran header file direktori pusat zip. Bidang sufiks externalFileAttributes dapat digunakan untuk menyimpan bit izin untuk setiap entri file/direktori.

cc @MarshallOfSound

saya memiliki masalah yang sama!

[gxz<strong i="6">@localhost</strong> build]$ ./Electron-0.1.1.AppImage 
[23154:0521/155029.728314: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-E0wZecV/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap(吐核)
[gxz<strong i="7">@localhost</strong> build]$ sudo ./Electron-0.1.1.AppImage 
[sudo] gxz 的密码：
[23191:0521/155048.067790:FATAL:electron_main_delegate.cc(211)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Trace/breakpoint trap
[gxz<strong i="8">@localhost</strong> build]$ 

dijalankan sebagai pengguna biasa, memiliki kesalahan: FATAL:setuid_sandbox_host.cc(157)] sebagai root, memiliki kesalahan: FATAL:electron_main_delegate.cc(211)]

tetapi ketika saya yum menginstal snap after， run as root atau user normal ok。

sudo chown root chrome-sandbox
sudo chmod 4755 chrome-sandbox

Ini bekerja dengan baik.

@cuixiping berfungsi :+1:

ya

$ find . -name chrome-sandbox
./node_modules/electron/dist/chrome-sandbox

$ sudo chown root ./node_modules/electron/dist/chrome-sandbox

$ sudo chmod 4755 ./node_modules/electron/dist/chrome-sandbox

Saya memiliki masalah yang sama ketika saya menjalankan elektron di Deepin dan saya telah menyelesaikan masalah dengan kode ini
electron . --no-sandbox

semoga itu membantu Anda

tidak bekerja

@fabiospampinato adaptasi Anda menonaktifkan kotak pasir untuk semua jenis paket Linux tetapi setidaknya paket DEB dan Pacman bekerja dengan baik dengan kotak pasir SUID (mungkin semua paket yang tidak seperti wadah), hanya perlu mengatur bit izin SUID ke chrome-sandbox biner. Tapi jangan atur bit izin SUID untuk paket Snap karena Snap Store menolak paket semacam itu. Jadi saya menetapkan bit SUID untuk semua paket Linux mengharapkan paket Snap/AppImage yang menonaktifkan sandboxing, kode terkait .

Hai @vladimiry
Saya tidak dapat mengakses tautan yang Anda lampirkan di sini. Bisakah Anda membantu dengan itu?
Selain itu, apakah Anda dapat mengetahui cara melakukan --no-sandbox di skrip after-pack pembuat elektron?

Terima kasih

@tushar-compro, ini dia https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Pada dasarnya saya mengatur 4755 bit dalam skrip after-pack untuk beberapa jenis paket dan masih mengemas ulang paket appimage+snap. Sebenarnya pembuat elektron telah menyematkan --no-sandbox arg ke dalam snap tetapi belum di appimage https://github.com/electron-userland/electron-builder/pull/4496. Beli caranya, hari ini pembuat elektron sudah menetapkan 4755 bit https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl #L7. Jadi versi pembuat elektron terbaru harus menyederhanakan banyak hal untuk sebagian besar pengembang.

@vladimiry
Apakah saya benar dalam memahami bahwa Anda telah menetapkan 4755 bit untuk target SELAIN appimage dan snap.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Namun masalah terjadi saat menggunakan .appimage installer di distro debian.

Apakah saya melewatkan sesuatu di sini?

Namun masalah terjadi saat menggunakan .appimage installer di distro debian.

Seperti yang saya katakan, appimage masih memerlukan perawatan khusus. Saya mengemasnya kembali dan menyematkan --no-sandbox ke dalam skrip ./AppRun . Temukan kata kunci DISABLE_SANDBOX_ARGS_LINE sini https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Namun masalah terjadi saat menggunakan .appimage installer di distro debian.

Seperti yang saya katakan, appimage masih memerlukan perawatan khusus. Saya mengemasnya kembali dan menyematkan --no-sandbox ke dalam skrip ./AppRun . Temukan kata kunci DISABLE_SANDBOX_ARGS_LINE sini https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

pembangun elektron terbaru menangani argumen no sanbox secara otomatis di snap dan appimage.

@vladimiry
Jadi, apakah saya benar untuk memahami bahwa pengaturan 4755 bit yang telah Anda lakukan adalah untuk penginstal selain appimage dan snap. Dan untuk appimage Anda telah menyetel no-sandbox. Bisa tolong konfirmasi.

@p3x-robot
Ya. Anda benar sebagian.

1. Pembuat elektron terbaru menetapkan tanpa kotak pasir untuk jepret tetapi BUKAN untuk gambar aplikasi. Namun, mereka telah menetapkan 4755 bit untuk appimage.
2. Dalam proyek saya, saya menggunakan versi elektron 20.xx Memperbaruinya ke 22.xx akan menjadi upaya tersendiri. Hanya berusaha menghindarinya jika memungkinkan. Memperbarui ke v22 akan menjadi pilihan terakhir.

pembangun elektron terbaru menangani argumen no sanbox secara otomatis di snap dan appimage.

Belum dapat menemukan dalam kode mereka cuplikan khusus appimage yang mirip dengan yang ini diterapkan untuk snap (https://github.com/electron-userland/electron-builder/pull/4496 masih terbuka). Bagaimanapun dalam kasus saya, pengemasan ulang masih diperlukan karena saya meletakkan argumen tambahan di sana, selain yang terkait dengan sanbox.

Jadi, apakah saya benar untuk memahami bahwa pengaturan 4755 bit yang telah Anda lakukan adalah untuk penginstal selain appimage dan snap. Dan untuk appimage Anda telah menyetel no-sandbox. Bisa tolong konfirmasi.

Benar. Tetapi pembangun elektron modern menetapkan 4755 secara internal. Saya memeriksa bahwa itu tidak disetel untuk snap/appimage karena itu akan menjadi kesalahan. Misalnya snap tidak akan dimulai dengan 4755 bit yang disetel ke biner elektron jika saya mengingatnya dengan benar.

@vladimiry
Saya hanya perlu mengatur no-sandbox karena gambar aplikasi saya tidak berfungsi di debian.

Saya yakin saya tidak perlu mengemas ulang dalam kasus ini. Tetapi saya tidak dapat menemukan dokumentasi yang tepat dari pembuat elektron untuk melakukan itu. Atau apakah Anda pikir saya juga perlu mengemas ulang?

Bisakah Anda mengarahkan saya ke dokumentasi yang tepat yang dapat membantu saya dalam cara melakukannya.

Selain itu, saya mengerti bahwa saya memiliki kedua opsi baik pengaturan 4755 bit atau pengaturan tanpa kotak pasir.
Mana yang menurut Anda lebih baik?

Selain itu, saya mengerti bahwa saya memiliki kedua opsi baik pengaturan 4755 bit atau pengaturan tanpa kotak pasir.

Jika saya mengingatnya dengan benar, pengaturan 4755 ke appimage tidak akan menyelesaikan masalah. Anda perlu (salah satu dari):

• mulai file appimage Anda dengan --no-sandbox baris perintah arg
• memiliki --no-sandbox disematkan ke dalam skrip ./AppRun terletak di file appimage Anda (jadi perlu pengemasan ulang).

Bisakah Anda mengarahkan saya ke dokumentasi yang tepat yang dapat membantu saya dalam cara melakukannya.

Saya ragu Anda akan menemukan informasi mendetail tentang masalah ini dalam dokumentasi apa pun. Saya tidak mengetahui adanya dokumen yang relevan.

Selain itu, saya mengerti bahwa saya memiliki kedua opsi baik pengaturan 4755 bit atau pengaturan tanpa kotak pasir.

Jika saya mengingatnya dengan benar, pengaturan 4755 ke appimage tidak akan menyelesaikan masalah. Anda perlu (salah satu dari):

• mulai dengan --no-sandbox baris perintah arg
• memiliki --no-sandbox disematkan ke dalam skrip ./AppRun terletak di file appiamge Anda (jadi perlu pengemasan ulang).

Bisakah Anda mengarahkan saya ke dokumentasi yang tepat yang dapat membantu saya dalam cara melakukannya.

Saya ragu Anda akan menemukan informasi mendetail tentang masalah ini dalam dokumentasi apa pun. Saya tidak mengetahui adanya dokumen yang relevan.

electron builder terbaru menyematkan --no-sandbox di ./AppRun , saya dulu mengemas ulang, tetapi sekarang tidak berguna, saya hanya menggunakan pembuat elektron asli.

@vladimiry
Ya. pengaturan 4755 saja tidak akan berfungsi. Dengan 4755 kita perlu mengubah pemilik chrome-sandbox menjadi root.
Bagaimanapun, terima kasih banyak atas bantuan Anda. Saya akan mencoba merujuk kode Anda dan mengatur no-sandbox.

@p3x-robot
Bisakah Anda membagikan beberapa tautan (repo pembangun elektron) di mana kami dapat melihat kode melakukan ini.

https://github.com/patrikx3/onenote

@vladimiry
Ya. pengaturan 4755 saja tidak akan berfungsi. Dengan 4755 kita perlu mengubah pemilik chrome-sandbox menjadi root.
Bagaimanapun, terima kasih banyak atas bantuan Anda. Saya akan mencoba merujuk kode Anda dan mengatur no-sandbox.

@p3x-robot
Bisakah Anda membagikan beberapa tautan (repo pembangun elektron) di mana kami dapat melihat kode melakukan ini.

https://github.com/patrikx3/onenote

pembuat elektron terbaru menyematkan --no-sandbox di ./AppRun, saya dulu mengemas ulang, tetapi sekarang tidak berguna, saya hanya menggunakan pembangun elektron asli.

Saya baru saja mengujinya menggunakan versi pembuat elektron terbaru dan itu tidak menyematkan --no-sandbox di skrip ./AppRun sh. Jika Anda memulai appimage, itu gagal dengan kesalahan seperti [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found diketahui. Mungkin Anda telah mengaktifkan flag kernel.unprivileged_userns_clone di sistem Anda. Jika demikian coba nonaktifkan seperti sudo sysctl kernel.unprivileged_userns_clone=0 dan mulai file appimage lagi.

pembuat elektron terbaru menyematkan --no-sandbox di ./AppRun, saya dulu mengemas ulang, tetapi sekarang tidak berguna, saya hanya menggunakan pembangun elektron asli.

Saya baru saja mengujinya menggunakan versi pembuat elektron terbaru dan itu tidak menyematkan --no-sandbox di skrip ./AppRun sh. Jika Anda memulai appimage, itu gagal dengan kesalahan seperti [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found diketahui. Mungkin Anda telah mengaktifkan flag kernel.unprivileged_userns_clone di sistem Anda. Jika demikian coba nonaktifkan seperti sudo sysctl kernel.unprivileged_userns_clone=0 dan mulai file appimage lagi.

aneh, ada instalasi snap 10k dengan pembangun elektron terbaru. dan pasti pembangun elektron menunjukkan bahwa ia menambahkan bendera itu ...

ada 10k jepret

Kita berbicara tentang appimage, bukan snap. Snap tentu saja memiliki argumen yang disematkan seperti yang saya rujuk di atas, di sini https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

ada 10k jepret

Kita berbicara tentang appimage, bukan snap. Snap tentu saja memiliki argumen yang disematkan seperti yang saya rujuk di atas, di sini https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

kamu benar. saya berpikir untuk beberapa alasan itu dilakukan di appimage, saya bahkan menghapus kode untuk paket ulang dan menambahkan tanpa kotak pasir, tetapi saya mencoba lagi dan saya melihatnya hilang, jadi saya menambahkan pengembalian build saya, bukan bekerja. maaf, di pembuat corifeus saya, Anda dapat melihat apa yang saya lakukan: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Hai @nornagon mengingat seberapa umum masalah ini, dapatkah tutorial memulai cepat elektron resmi diperbarui untuk menyertakan solusi sehingga pemula memiliki pengalaman positif?

Sunting: Berkat dorongan komunitas, saya telah membuka FR #26478

@gabefair Itu sepertinya proposal yang masuk akal. Apakah Anda tertarik untuk membuka PR?