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.

[michaelneverwins]

why not just have it detect if the OS has one installed, and use that?

This would be ideal. I don't want firejail installed twice, nor do I want itch using an older version.

I do have a workaround which I've used to get itch using my system's firejail, although I can't promise it won't lead to unexpected behavior.

After itch asked for super user authentication to set up the sandbox — which, incidentally, I denied, because I didn't understand what it was doing (because I had forgotten that I had enabled the sandbox feature after the last time I had launched a game through the app) — I ran find ~/.config/itch -name firejail and found that a copy of firejail (0.9.52) was downloaded to ~/.config/itch/prereqs/firejail-amd64/firejail. (The exact path might not be the same for everyone.) So I replaced this file with a symbolic link to the copy of firejail installed by my package manager, and itch was then able to launch my games in firejail without asking for super user authentication (because of course the system copy of firejail already has the SUID bit set).

This workaround can be done at the command line as follows:

ln -sf `which firejail` ~/.config/itch/prereqs/firejail-amd64/firejail

Note that the -f flag to ln will make it remove any existing firejail executable downloaded by itch. I was going to suggest renaming the itch-installed copy of firejail rather than removing it, but we can always make itch download it again. Successfully undoing this hack is slightly trickier than I'd first assumed, because simply deleting the ~/.config/itch/prereqs/firejail-amd64/firejail link will cause itch to show a "no such file" error rather than re-downloading firejail, but this appears to be due to a hidden file ~/.config/itch/prereqs/firejail-amd64/.installed which appears when itch has successfully run firejail and causes itch to skip the firejail set-up. If that file is deleted, itch will re-do the firejail set-up. But really, the easiest way to reset everything is just to delete the folder:

rm -r ~/.config/itch/prereqs/firejail-amd64/

I also tested this symbolic link workaround with a fresh install, to see if I could avoid having itch download firejail in the first place, and it seems to work. I wiped out my itch installation by deleting ~/.itch and ~/.config/itch (but not my games which are installed in a different location), re-installed the app, started the app (to add my custom game install location back in), stopped the app, and ran the following commands:

mkdir -p ~/.config/itch/prereqs/firejail-amd64
ln -s `which firejail` ~/.config/itch/prereqs/firejail-amd64/firejail

Then I started the app again, enabled the sandbox feature, and tried launching a game. It started right up without any apparent sandbox setup (i.e. I didn't see the pop-up window about downloading firejail nor was there any request for super user authentication). Use of pgrep while the game was running confirmed that firejail was being used. Again, I was then able to undo this workaround (and get itch to download its own firejail) simply by removing the folder:

rm -r ~/.config/itch/prereqs/firejail-amd64/

Anyway, I hope this helps, but be aware that this is a hack. If you're going to attempt such hacks, I would recommend keeping games installed to a location outside of ~/.config/itch so you can remove the entire directory and start fresh if things get really screwed up.

Edit: Based on #2732, it looks like the directory which is ~/.config/itch/prereqs/firejail-amd64 on my machine may also be ~/.config/itch/prereqs/firejail-386. I assume this is meant to reflect the machine architecture. The bug described there actually seems to show itch getting confused about what the architecture is when running Windows games on Linux, but the workaround already suggested there is similar to what I've described above (just with a different directory name); see https://github.com/itchio/itch/issues/2732#issuecomment-1063265071.