You're welcome. I also added Code: https://github.com/netblue30/firejail/commits/master.atom to my RSS reader, so it's easy to see if I should start that script again.
This is another example how badly packages in Ubuntu universe are maintained. The newest Firejail versions in which several security flaws are fixed are 0.9.44.4 and 0.9.38.8. Now look what the status in Ubuntu is: Firejail is only up-to-date in Ubuntu Zesty (to be released in April 2017!). In 16.04 LTS it's 0.9.38-1 - last updated on 07 Feb 2016, and in 16.10 it's 0.9.40-3 - last updated on 14 Jun 2016. Although multiple issues in several versions had been fixed in the meantime. This is a disaster. And it confirms what I said in another thread here: Don't trust packages in universe. You can never be sure that they are well maintained.
@summerheat Thank you for noting that. I need to start pointing friends to Debian instead of Ubuntu... sigh.
You're welcome. I was referring to this thread. And yes, I think that Debian is a better choice security-wise as it's hardly possible in Ubuntu to avoid packages from universe.
Firejail 0.9.44.6 and 0.9.38.10 LTS released. Please update as those versions contain security and other fixes.
Since updating to the latest version of Firejail, 0.9.44.6_1, I am noticing a difference in the way it functions with Firefox, at least cosmetically. Usually anytime I open FF with "firejail firefox" the top of the FF window would say "Mozilla Firefox (as superuser)". Now it only does that upon initially opening FF after first boot but not other times. Every time thereafter it just says "Mozilla Firefox", unless I'm using "firejail --private-home=.mozilla firefox", then it still says (as superuser) each time. The same processes seem to be running in System Monitor each way though. As stated earlier in this thread I'm pretty new to Linux. I just want to be sure Firejail isn't misbehaving or I didn't mess something up when I updated. I couldn't find any instructions on how to update it like, unistall old version then install new, install over the top, reboot between, etc. I uninstalled the old, installed the new, then rebooted. Maybe I should have rebooted between the old version uninstall and the new version install. Any thoughts from other users would be appreciated.
No expert on firejail and others may have a better idea or even know what's happening in your case, but you could try the firejail --tree command as seen below. It will at least show the browser running under a child PID process which will indicate it's being sandboxed. Otherwise, I have no idea about what you're seeing. Hopefully it's nothing serious. My results show the parent PID as 8175, and the child PID as 8178. BTW, I'm using the latest current v0.9.44.6 Code: username@username-desktop:~$ firejail --tree 8175:username:firejail --nonewprivs --x11=xorg --caps.keep=sys_chroot,sys_admin,sys_time,sys_tty 8178:username:firejail --nonewprivs --x11=xorg --caps.keep=sys_chroot,sys_admin,sys_time,sys_t 8191:username:/usr/lib/chromium-browser/chromium-browser --ppapi-flash-path=/usr/lib/adobe-f 8211:username:/usr/lib/chromium-browser/chromium-browser --type=zygote --ppapi-flash-path= 8213:username:/usr/lib/chromium-browser/chromium-browser --type=zygote --ppapi-flash-pat 8248:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc 8250:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc 8251:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc 8264:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc 8266:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc 8284:username:/usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinc
This is what I see running that command both ways: username@username-desktop ~ $ firejail --tree 3371:username:firejail --private-home=.mozilla firefox 3374:username:firejail --private-home=.mozilla firefox 3383:username:/usr/lib/firefox/firefox username@username-desktop ~ $ firejail --tree 3849:username:firejail firefox 3852:username:firejail firefox 3858:username:/usr/lib/firefox/firefox I may just go back to the older version and try updating again to see if makes any difference. How do you like to update FireJail if I may ask?
Nothing special, just download the .tar.xv file then navigate using terminal to the folder and run these commands: Code: tar xf firejail-0.9.44.6.tar.xz cd firejail-0.9.44.6 ./configure make sudo make install then just to make sure it's installed properly I type: firejail --help
So Firefox is running as user and not as root (or "superuser"). This will also be confirmed with, e.g., htop or ps aux. I remember that I had seen this discussed on the Firejail github site. In several comments it became obvious that this superuser hint is displayed or not depending on which distro and/or windows/dektop manager is used. This is probably caused by the fact that Firejail starts as root and drops its privileges once everything is configured - more details here. But in any case the application itself is running as user so you don't have to worry. That depends. If you're running the stable or LTS version there are ready-to-use deb and rpm files here. For other distros which do not offer Firejail in their repos you can do what wat0114 suggested. And if you want to use the newest git version you can use a script like this one.
Yes, I always download the deb file from https://sourceforge.net/projects/firejail/files/firejail/. I was asking about whether it's best practice to uninstall the old version before installing the new or if I could just install over the top of the old.
No, the old version doesn't need to be uninstalled. BTW: Version 0.9.44.8 is released with just one bugfix: fix broken PulseAudio support.
Thanks Summerheat, I installed the new version and it fixed the "superuser" display issue I had mentioned.
As mentioned above there's no reason to be worried. If you don't believe what firejail --list or filejail --tree displays, I suggest that you execute htop: It confirms that firejail and firefox are running as user. (You might have to install htop first.) Edit: Alternatively you can also execute ps aux | grep -e firejail -e firefox
I'm not saying that I don't believe the security is any less now; just that there is a difference in the last two versions than the one before them.
@summerheat, I ran your script yesterday and it seemed to work fine except that it somehow broke chromium-browser. There was no way it would open either sandboxed or not. Tried re-installing, re-installed firejail, deleted firejail, removed chromium and re-installed even without firejail but still no way it would launch. Not even showing a process in task manager. Weird to say the least No problems running firefox, thunderbird and deadbeef sandboxed. No solutions online found, either, so I just restored a fairly recent image and all is okay. BTW, not necessarily your script to blame, because over the last while I've done all kinds of different minor modifications with chromium, so maybe that was a contributor. I'll just stick to the manual method of updating firejail instead
Yes, indeed. I've never had that problem, and it's interesting that it happens only with Chromium. I'm confident that it's not related to the script as it follows netblue30's instructions how to do and it just compiles the git version on your computer instead of downloading a pre-compiled package. The end-result is the same (barring the fact that there is no pre-compiled git version). I don't use Chromium - but here are some thoughts: 1. You say: "There was no way it would open either sandboxed or not." How do you make sure that it is not sandboxed? I mean: How do you normally start Chromium sandboxed? By editing the entry in the start menu or by using symlink invocation? In the latter case - did you make sure that you removed the chromium symlink in /usr/local/bin in order to start it unsandboxed? 2. What's the entry in the start menu? Is it simply chromium or is it /usr/bin/chromium? In the latter case (using the absolute path) symlink invocation wouldn't work. 3. Actually the most important question: What messages do you get if you start chromium in the console?[/USER]
I had created a separate desktop launcher to force it sandboxed with options. Otherwise I had the default launch icons, one on the panel and one in the start menu to launch it non-sandboxed. The entry on the latter two was just "Chromium-browser %U". I had played around with symlinks once so maybe they were the culprit? i had though about it but never pursued that possibility. As for trying to open in the console I can't remember the result. Since my system image was quite recent, I just restored it rather than spending more time troubleshooting. Too lazy I guess to bother any more
Hm, why did you that? Just out of curiosity. Well, there's actually no need any more to manually "play" around with symlinks. Just execute sudo firecfg in order to create symlinks in /usr/local/bin for all applications supported by Firejail. firecfg --list shows the existing symlinks, firecfg --fix (executed as user) fixes .desktop files which contain absolute paths to applications. See man firecfg. In any case, if a symlink for chromium existed in /usr/local/bin this would explain that you couldn't execute it "unsandboxed" because actually it still would have been sandboxed. So possible individual changes (e.g. concerning caps.keep) in the profile would apply. That makes it difficult to find the culprit
using the --private-home option meant that any updates to the browser, especially extensions had to be done un-sandboxed. Actually, the problems I had extended beyond the browser not opening; updates via apt-get update were not working right, with missing repository urls and key problems. No amount of research could rectify the problem. I also seemed to have firejail directories in several places - something just didn't look right - and I can't help but wonder if that may have been the issue with chromium breaking. It looks cleaner now, the way I would expect it to look. I remember a while back there was an issue with two different versions of firejail installed at once. I don't know how it happened, but somehow I fixed it, though I think it left things in a bit of a mess. When I restore an image, I know it's "clean" , so I have guarantees there are not other unknown problems left over even if I'm able to fix the primary one.
Okay, I understand. I guess that you had two versions after using the script. The only explanantion that comes to my mind is that you didn't add the --prefix=/usr switch to the ./configure line. Without that switch everything is installed under /usr/local including the firejail executable. E.g., the profiles would be now in /usr/local/etc. See line #571 in ~/firejail/configure. I don't know why it's done that way. Anyway, using the --prefix=/usr switch makes it behave like the pre-compiled versions.
When I run a find / -name "firejail" command I see it in the following locations" Code: /usr/local/bin/firejail /usr/local/lib/firejail /usr/local/etc/firejail /usr/local/share/doc/firejail /usr/local/share/bash-completion/completions/firejail I guess this makes sense since I didn't use the --prefix=/usr switch.
Sorry confusion on my part in the way I explained things. I need to clarify that in original installations of firejail I used the manual method: Code: tar xf firejail-0.9.44.6.tar.xz cd firejail-0.9.44.6 ./configure make sudo make install ...but when I used your script I did include the --prefix=/usr switch. Could this have been why the installation messed up, because the script method conflicted with mine? That said, I know there were issues before I even used your script, especially when I mentioned earlier about two different versions of firejail installed simultaneously. At least it's all sorted now and I'll be careful about future upgrades.