@summerheat Including, apparently, an X11 sandboxing method using built-in X extensions! And a way of turning off 3D acceleration support for sandboxed apps. I'm not sure when the new version will show up in Debian Testing so I can try it out. Right now though, I'm quite interested in reports of how the new features work. X11 is a huge security hole, but xpra is very slow and Xephyr is irritating to use, so a less flimsy method of X11 isolation would be a good thing... Likewise for 3D support, which is nice to have for some local programs but not so much for your browser.
I haven't thoroughly tested X11 sandboxing myself - it's still on my todo list. On the other hand, Wayland is not far away ... BTW, you can download the .deb file here if you want to test it right now.
FYI 0.9.44 just hit my mirror yesterday on Arch. Going to be playing around with it over the next few days...
Apparently there was a CVE in Firejail that was fixed in 9.44, I imagine that was fixed in the LTS version also but I don't see anything on that though the CVE may have only affected the newer versions due to feature changes. http://seclists.org/oss-sec/2016/q4/230 https://github.com/netblue30/firejail/commit/46dc2b34f1fbbc4597
I hadn't installed it but I just did as a service for you Yes, it's running on Firejail 0.9.44. However, at first it didn't. I had executed sudo firecfg in order to create the symlink in /usr/local/bin. Then I started Gimp - but it wasn't sandboxed! The solution was simple, though: The entry in the KDE start menu was stupidly gimp-2.8 %U After changing that to gimp %U (because there is a symlink gimp in /usr/bin which points to gimp-2.8 - why didn't they use it in the first place ) all is well. I haven't tested it extensively but so far no problems. EDIT: This is one example why one should check if a freshly installed application is really running sandboxed (provided a Firejail profile exists and sudo firecfg was executed). Another example was Chromium which I had installed a while ago and didn't start sandboxed. Not surprising: In the KDE start menu was the absolute path /usr/bin/chromium so the symlink in /usr/local/bin wasn't triggered. Another stupidity.
@summerheat Thanks a lot man I owe you. Editing to just "gimp" makes it start, but not if I right-click on an image and select "open with Gimp". I think disabling private-tmp could solve it. Hold on. Yup, that did it. BTW, I don't use firecfg, I edit all my menus and add "firejail " to them. Works beautifully (except in such cases as this one). And even if there's not a profile, it loads a few ones such as "disable-common" and the other ones which are automatically loaded. Cheers man
You're welcome, my friend! Ha - that's the reason why right-click and select "open with Gimp" doesn't work! I strongly suggest that you use sudo firecfg because it automates what was introduced in v. 0.9.38 as symlink invocation. It creates symlinks to /usr/bin/firejail for your installed applications (with existing Firejail profiles) in /usr/local/bin. If you execute Code: echo $PATH you'll see that /usr/local/bin comes before /usr/bin. This makes sure that when executing, e.g., gimp the respective symlink to Firejail is triggered - even if gimp (or okular or whatever) is executed not from the start menu but as helper application in, e.g., a file manager. This is a great feature which works reliably unless the absolute path to the helper application (i.e. /usr/bin/gimp) is used (as shown in the example in my post above). In such a case you should edit that entry and modify it a simple gimp.
@summerheat Great info, thanks! However, let's say I edit the KDE menu so that "Gwenview" has "firejail " in front of the command. If I open Dolphin (un-firejailed) and then a picture, that picture will be opened in a firejailed Gwenview nevertheless. Are you sure there's a chance that e.g. gwenview won't launch firejailed (thus requiring me to issue firecfg)?
Ive noticed if I run Firejail with the -x11 switches, the theming will break and I'll get screen-tearing; this makes sense though of course, and otherwise FF works perfect using both -x11=xephyr and -x11=xorg. Ill have to mess with it later and figure out if I can get compositing on the sandboxed window and if I can get the theming imported (I have FF set to match my gtk/wm theme). For now I've reverted back to using Firejail without the -x11 switch, but it looks to be a great development. This should certainly improve security especially for web browsers.
In my understanding this requires that this change is reflected in the corresponding entry in mimeapps.list. However, in my experience this is not always handled in a consistent and reliable way in the various distros. It can work for a specific application but it might not work for another. Symlink invocation (as automated by firecfg) is the most reliable way, IMHO. As you know, PATH is an environmental variable which tells the system which directories to search for executables. Whatever is found first during this search will be used. That's why the symlinks in /usr/local/bin (which point to /usr/bin/firejail) will be found and used prior to the executables in /usr/bin. As mentioned, this works reliably unless absolute paths are used.
Okay, 0.9.44 is now in Debian Testing! And, contrary to the warnings on the man page, Chromium works okay with Xorg sandboxing. Not sure yet how effective it is though. (Also there's a profile for Virtualbox. Very minimal though, as you might guess.)
Well, a lot is already blacklisted by the *.inc files, and there are some other restrictions. But you can easily tighten that profile by creating a virtualbox.profile in ~/.config/firejail like this: Code: ... your own rules ... include /etc/firejail/virtualbox.profile It takes precedence over the one in /etc/firejail. You could, e.g., whitelist the directories needed which would block access to any other directories/files in home.
@summerheat I need you again, my man :/ I can't start Steam through Firejail on Ubuntu 16.04. Code: Error: Couldn't find bootstrap, it's not safe to reset Steam. Please contact technical support
Sorry, I can't help here as I don't use Steam (nor Ubuntu). But I've noticed that you reported the problem to netblue30. I'm certain that he will be able to solve the problem.
@SuperSapien It depends on which kernel exploits. Off the top of my head, I don't know whether it helps with Dirty Cow. Access control is in general good to have, and can block or hinder a lot of exploits; but is no substitute for avoiding software holes in the first place.
FWIW, I'm using a little script to always use the latest git version: Code: rm -rf ~/firejail git clone https://github.com/netblue30/firejail.git cd firejail ./configure --prefix=/usr make sudo make install If you want to enable AppArmor support, just change the .configure line to: Code: ./configure --prefix=/usr --enable-apparmor
Thank you for the tip, summerheat. There are now new releases available from the Project webpage with security fixes, including the root exploit...