So electron improved their security features with the recent version 5, but by doing this broke tons of applications because they either need User Namespaces or an SUID executeable (to launch proper isolated subprocesses).
#Signal Desktop noticed this problem and as well and "fixed" it in the worst way possible:
On the other hand #Riot Desktop did a proper fix, which enables an SUID bit on this binary: https://github.com/vector-im/riot-web/commit/56674ea70849b3a793fa7b862945163aa10b36b8
Little follow up on my earlier statement about #Signal Desktop and the `--no-sandbox` argument they force on linux now.
I didn't just made noise on my social media but of course also (tried to) work with the upstream project. Sadly it seems like they don't care:
5 work days and no one even had a look at it. Great… Maybe I should write a PR this weekend in hope it gets more attention.
@sheogorath Is there a post anywhere explaining what they are fucking up on here? what are the implications? asking cause I don’t understand and would like to
@liaizon Here you go:
Which is basically based on the Chromium Sandbox:
For simple explanation:
@sheogorath I assume the simple explanation isn’t really appropriate in this case as Signal is not letting you navigate outside of its own services. Like how would one take advantage of this insecurity?
@liaizon Yes, chromium spreads out different tasks to different processes which then get only the right amount of capabilities to "get the job done". You can check that in your process manager (on linux you can open a shell and run `ps aux | grep signal`) to see this in action.
When it comes to Electron, well, not per se. Electron has the potential to be a big security problem, but a bad written own client could be even worse.
Security comes from writing good code, not from the framework.
the personal instance of Liaizon Wakest