Update firejail

[saildata]

It looks like the firejail version is from summer 2016, which does not include several major security updates (see firejail RELNOTES for more information and CVE refs).

Maybe it makes sense to allow an install/config option user flag to disable, assuming that they will be running the parent (itch app) in a SUID sandbox. If running the children in a SUID sandbox makes sense, why not the parent? Hopefully that doesn't sound sarcastic, it's not meant to be.

Thanks for your hard work, it's very much appreciated.

Cheers --

[fasterthanlime]

It looks like the firejail version is from summer 2016, which does not include several major security updates (see firejail RELNOTES for more information and CVE refs).

That's a very good point, thanks for bringing it up! Sounds like a good occasion to solve #1146 as well.

Maybe it makes sense to allow an install/config option user flag to disable, assuming that they will be running the parent (itch app) in a SUID sandbox. If running the children in a SUID sandbox makes sense, why not the parent? Hopefully that doesn't sound sarcastic, it's not meant to be.

No worries, this is a very good point as well. There are things itch needs to do that it couldn't do if it were completely sandboxed. My understanding is that electron renderer processes (much like Chrome's) are already sandboxed (because of WebGL for example, which seems to be a source of security bugs), but it would be nice to be able to confirm that.

I'm confused by the "option to disable" though - if you've somehow managed to sandbox the whole itch app (including any child processes it can spawn) then you can just uncheck "itch.io sandbox" in Preferences, seems like that part is already done?

[saildata]

That's a very good point, thanks for bringing it up! Sounds like a good occasion to solve #1146 as well.

• Thank you for the quick response! It looks like everyone is taking a closer look at how to best mitigate, as the currently patched branch is the Master branch. I use the git version and have to build from source every 2 weeks or so, but luckily that's all pretty automated.

No worries, this is a very good point as well. There are things itch needs to do that it couldn't do if it were completely sandboxed. My understanding is that electron renderer processes (much like Chrome's) are already sandboxed (because of WebGL for example, which seems to be a source of security bugs), but it would be nice to be able to confirm that.

• I have always heard to avoid SUID where possible - and I know that some distributions disable them except for the obvious ones like passwd and sudo/su. I assume through lots of custom capability management in systemd units or similar alternatives. RHL recommends using a combination of their Atomic Host images and Docker.

• One alternative, from the base package, util-linux, is something like setpriv and/or runuser. "Set various kernel privilege bits and run something" (without installing SUID).

• I'm sure if you ask 5 Linux users which option is best and you'll get 10 answers. Without a lot of new code, it sounds like sticking with your original plan is a good one.. (using firejail)

I'm confused by the "option to disable" though - if you've somehow managed to sandbox the whole itch app (including any child processes it can spawn) then you can just uncheck "itch.io sandbox" in Preferences, seems like that part is already done?

• You are 100% correct. I never see that down in the bottom left! It's usually after I've tried right clicking on the toolbar icon in Gnome lol. Bad place for a feature request? jk : )

• I need to push it to my personal firejail launcher/script repo but I have a current script to launch Chrome in a full IPS (drop all capabilities but CAP_SYS_CHROOT and run it in an overlayfs/the whole nine yards). It complains a LOT and definitely breaks every now and then.. not for the faint of heart. So your original is actually sounding better and better.

• I see itch is linked to 45 libraries on my machine. I wish I could just drop in a bind mount to my native firejail executable, but its not portable. So I guess using the native firejail would require code update in itch to remove the previous one and wrap the games with the system installed version. Not trying to make a lot of work here, just thinking out loud...

Thanks again for taking the time to look into this. I'm a huge fan of the project and need to contribute some bug fixes for each of these essays I put you through :book:

[Dimensional]

Looking this over, why not just have it detect if the OS has one installed, and use that? Would cut down on bandwidth, and would use one pre-installed, which may even be one part of the OS's repository, and as such may be a newer version with bug fixes.