An even more powerful sandbox for Firefox, use the --seccomp switch: Code: firejail --seccomp --profile=/etc/firejail/firefox.profile --private.keep=.mozilla,Firefox_Temp firefox
An example using the --debug switch to show the effects of sandboxing Chromium browser this way: I can't explain the warnings near the end but there are no noticeable issues using the browser this way.
@ wat0114 Thanks for all the helpful information. It's nice to have instructions. Being as I'm mostly used to Windows, it sure would be nice if the GUI included more options for setting things up. Maybe the author will continue to develop it.
You're welcome, Firebytes. Firejail has so many options, most of which I've never used, so it looks like like one can tailor it to their needs in so many different ways.
Why are you giving full paths to firejail application profiles, there is no need to. A simple $ firejail firefox or $ firejail --private.keep=.mozilla firefox should suffice. What happens is that if there is a profile for the application in /etc/firejail or ~/.config/firejail, firejail automatically loads that profile. And there is no need to use the seccomp flag manually, it's already there in default firefox profile. I would suggest those starting with firejail to avoid the gui tool, and instead create launchers for easier access. Give it a name, application with firejail ( application can be firefox, chromium and any other app you want) and in the command field write the appropriate command.
@UnknownK For example, one can extract the .deb package of Steam on the home folder and execute it from there. It will not install anything outside of the /home folder, it will create it's own set of directories There are other examples such as X-Plane's installer for Linux, or this helicopter for X-Plane that requires one to execute the installer. None of these two require root priviledges, they execute directly from the folder you extracted them.
Yes, now I understand. You can sandbox them. I sandbox my TBB bundle which is not installed in the system. Just create a profile for it in ~/.config/firejail and name it after the executing script. Go to directory where the script is located and start firejail with $ firejail ./this-is-the-script-to-start-application-x-which-is-not-installed. For this you need to have this-is-the-script-to-start-application-x-which-is-not-installed.profile in ~/.config/firejail.
With your first command "firejail firefox" changes I make in the browser persist. The second one does seem to work, though, so thanks for that I'm not an expert on this application, just experimenting, trying to figure it out. Also, I didn't take a look at the Firefox profile, not knowing the seccomp switch was in it.
It looks like for chromium the command is simply: Code: $ firejail --private.keep=.config/chromium/ chromium ...that at least seems to work and of course similar idea for Firefox. Thanks for the clarification, Unknown. Still, $firejail firefox doesn't seem to discard changes made.
$ firejail firefox will persist the changes and is the default behaviour. $ firejail --private.keep=.mozilla firefox will mount a temporary file system on top of /home and will just copy the contents of ~/.mozilla to the temp fs. The changes will be discared after you close firefox. For semi-persistence there is another method. Just create a new folder named firefox_fj_home or whatever you may wish in your home directory. Start $ firejail --private=firefox_fj_home firefox. Whatever you download in that firefox instance, whatever addons you installed, whatever bookmarks you marked will stay in that folder even after you close that instance of firefox. In short, firefox_fj_home will behave like your actual home. You can remove firefox_fj_home afterwards if you don't want persistence.
I can see right now where for Firefox this is a great security method since their own sandbox is still not running by default but for Chrome/Chromium does this provide any further protection than it's own built in sandbox?
Firejail does offer further protection. You can prevent the browser, and in turn the attacker gaining control of the browser, from accessing sensitive user files and directories storing passwords, encryption keys and certificates, etc. You can block whatever files/directories you want. An attacker gaining control of the browser will have no access to them. Not possible with the default chrome/chromium sandbox. The ability to completely/selectively discard any changes to the system is another plus.
It seems Chrome has since dropped using the SUID sandbox. Sandbox Status SUID Sandbox No Namespace Sandbox Yes PID namespaces Yes Network namespaces Yes Seccomp-BPF sandbox Yes Seccomp-BPF sandbox supports TSYNC Yes Yama LSM enforcing Yes You are adequately sandboxed.
What kernel are you running? “The namespace sandbox aims to replace the setuid sandbox. It has the advantage of not requiring a setuid binary. It's based on (unprivileged) user namespaces in the Linux kernel. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported. Starting with M-43, if the kernel supports it, unprivileged namespaces are used instead of the setuid sandbox. Starting with M-44, certain processes run in their own PID namespace, which isolates them better.”
0.9.28 has been released in the last week: https://l3net.wordpress.com/projects/firejail/firejail-release-notes/ Apart from the ability to set up an extensive sandboxed network environment, the things that caught my eye were also support for a common directory blacklist definition, noroot option in profiles with noroot as defautl; and inclusion of the package in the Debian repositories. More to like. The comparison with Docker is interesting, in that they obviously use many similar techniques and kernel functionality. I think the key point is that Firejail works with uncooperative applications - in other words, pretty much all of them, plus gives you as user some control over the way it's configured, rather than having that defined as part of the package. What's truly shocking is the feeble extent to which applications use standard kernel functions to improve security in the first place, but then that doesn't bring in the cash and it's hard.
$ uname -r 4.1.4-1-ARCH Only the namespace sandbox is unavailable: SUID Sandbox Yes Namespace Sandbox No PID namespaces Yes Network namespaces Yes Seccomp-BPF sandbox Yes Seccomp-BPF sandbox supports TSYNC Yes Yama LSM enforcing Yes
https://goo.gl/4qdyck Compatibility Containers or plain chroots can throw a wrench into the ease of using TPE, as each one has a local /etc/group. A group with the same id in the container will still work as a whitelist, but this will be broken if the container makes use of user namespaces (not yet supported by Arch kernels).
