I don't know as I haven't checked how the configure file in that *.tar.xz file looks like. If it contains a line ac_default_prefix=/usr/local we've found the culprit.
BTW @summerheat, this discussion with you has been beneficial in other ways. After exploring through some of the firejail profiles, it occurred to me that I could simply put my options in the profile, rather than creating a separate launcher for them So now in the chromium.profile I've added: Code: caps.keep sys_chroot,sys_admin x11 xorg nonewprivs ...and deleted the custom launcher. I also generated symlinks with your suggestion: sudo firecfg Thanks for your help
That script works well but can be simplified by using git pull which fetches only changes from the git repository which makes the download size much smaller. So this is what I recommend: If you're installing the git branch of Firejail for the first time use this script: Code: cd ~ rm -rf ~/firejail git clone https://github.com/netblue30/firejail.git cd firejail ./configure --prefix=/usr make sudo make install From now on use this script in order to update Firejail: Code: cd ~/firejail git pull ./configure --prefix=/usr make sudo make install Works well for me.
Thanks summerheat! Will this script still work even if I installed firejail using one of the tar.xz archives from sourceforge?
Well, the ~/firejail diretory must exist and it must be identical with the one created by git clone. I don't know if that's the case.
Firejail doesn't come with ready-to-use profiles for those applications. So you have to create your own ones which shouldn't be too difficult. See also this site for whitelisted profiles.
I'm running the Openbox session of Lubuntu 16.04 with the version of Firejail that is supplied in the repos, version 0.9.38.10. I know it's old, but some sort of support is implied in https://firejail.wordpress.com/download-2/ by "Firejail Long Term Support: 0.9.38.10". My issue is that I couldn't get "--noprofile --overlay" to work with Firefox. The browser would open just fine but there wasn't any network connectivity. The same was true of two other browsers, netsurf and google-chrome. Then I came across https://github.com/netblue30/firejail/issues/151#issuecomment-159978829 and later comments in that same issue which related to a similar difficulty. It turns out that both the person who raised the issue and I are using WiFi and that that was the reason why just "--noprofile --overlay" doesn't work. The developer suggested trying Code: firejail --noprofile --overlay --dns=8.8.8.8 --dns=8.8.4.4 and this works for me. I'm very curious that in all the pages in this long thread there's just one mention, on the first page, of "--overlay". Why isn't "--overlay" more popular with Wilders' members?
Well, to quote from the man pages of my version: Code: --overlay Mount a filesystem overlay on top of the current filesystem. All filesystem modifications go into the overlay. The overlay is stored in $HOME/.firejail directory. OverlayFS support is required in Linux kernel for this option to work. OverlayFS was officially introduced in Linux kernel version 3.18 Example: $ firejail --overlay firefox --overlay-tmpfs Mount a filesystem overlay on top of the current filesystem. All filesystem modifications go into the overlay, and are discarded when the sandbox is closed. OverlayFS support is required in Linux kernel for this option to work. OverlayFS was officially introduced in Linux kernel version 3.18 Example: $ firejail --overlay-tmpfs firefox --overlay-clean Clean all overlays stored in $HOME/.firejail directory. Overlays created with --overlay-path=path outside $HOME/.firejail will not be deleted. Example: $ firejail --overlay-clean --private Mount new /root and /home/user directories in temporary filesysâ tems. All modifications are discarded when the sandbox is closed. Example: $ firejail --private firefox It seems somewhat related to "--private". And "--overlay-tmpfs" seems similar to "--private" though I don't know what advantage one has over the other.
For those of you who haven't noticed: About 2 weeks ago Firejail 0.9.48 was released with a couple of improvements. And there is good news for Chrome/Chromium users: On distributions with newer kernels (altough I don't know how new it has to be) and with user namespaces enabled (this should exclude, e.g., Arch Linux and RHEL, AFAIK) the Firejail sandbox can be much tighter than before. On my Fedora system I'm using the following custom profile for Chrome: Code: include /etc/firejail/google-chrome.profile include /etc/firejail/disable-devel.inc seccomp.keep access,arch_prctl,bind,brk,capget,capset,chdir,chmod,chroot,clock_getres,clone,close,connect,creat,dup,dup2,epoll_create,epoll_ctl,epoll_wait,eventfd2,execve,faccessat,fadvise64,fchmod,fcntl,fdatasync,fstat,fstatfs,ftruncate,futex,getdents,getdents64,getegid,geteuid,getgid,getpeername,getpgrp,getpid,getppid,getpriority,getrandom,getresgid,getresuid,getrlimit,getsockname,getsockopt,gettid,getuid,inotify_add_watch,inotify_init,inotify_init1,inotify_rm_watch,ioctl,kill,listen,lseek,lstat,madvise,memfd_create,mkdir,mmap,mprotect,munmap,nanosleep,newfstatat,open,openat,pipe,pipe2,poll,ppoll,prctl,pread64,pwrite64,read,readlink,readlinkat,recvfrom,recvmsg,rename,rmdir,rt_sigaction,rt_sigprocmask,rt_sigreturn,sched_getaffinity,sched_getparam,sched_getscheduler,sched_setscheduler,sched_yield,seccomp,select,sendmsg,sendto,setpriority,setrlimit,set_robust_list,setsockopt,set_tid_address,shutdown,socket,socketpair,stat,statfs,symlink,sysinfo,umask,uname,unlink,unshare,wait4,waitid,write,writev,setresuid,setresgid,exit_group,tgkill,exit,utimensat,personality,setxattr,mremap,clock_gettime caps.drop all nonewprivs noroot private-dev noexec ${HOME} noexec /tmp shell none ipc-namespace machine-id blacklist /boot blacklist /mnt This means that - particularly by adding caps.drop all, nonewprivs and noroot - the confinement of the broker process is now considerably stricter. The seccomp.keep line is rather long as expected and might look different for your distro. I suggest that you follow netblue30's guide here if you're running into problem. For example, if Chrome/Chromium doesn't start or something doesn't work as expected I would first comment the seccomp.keep line to make sure that it isn't the culprit. If the problem vanishes I would uncomment that line again. After launching (or trying to launch) the browser again I would execute (if your distro is using systemd): Code: journalctl -e | grep syscall If you see a message containing syscall=xxx you should execute that command shown in above guide: Code: firejail --debug-syscalls | grep xxx The result will be the syscall which should be added to the seccomp.keep line. It might be necessary to repeat that process several times. EDIT: FWIW, today I got the upgrade to Chrome v. 59.0.3071.115. It needs two syscalls more to be added to seccomp.keep, namely fchown and getcwd. I also added the nogroups option.
Very interesting: The 0.9.51 development version got a profile build tool which creates a whitelisted profile for a specific application. I have yet to test it but it should considerably simplify creating your own profiles.
Something strange about Firejail with Firefox and Noscript & WOT. Both NS and Web Of Trust are disabled in the default/standard profile (firejail firefox) but when use Private Home (firejail --private-home=.mozilla firefox) for Firefox there enabled, and when I say disabled I don't mean from about:addons but from the toolbar I mean its even disabled without the Firejail sandbox. Note: I'm using the current version of Firejail.
I'm not sure how I feel about user namespaces. On the one hand they offer a lot, but on the other they expose a lot of code that hasn't exactly had many eyes on it. There has been some discussion on firejail's spiraling complexity as it relates to exposure, but I'm not enough of security expert to make heads or tails of it all. Am I correct in assuming that removing "noroot" from a profile eliminates the use of user namespaces? Firejail still offers a ton of things beside user namespaces, and in conjunction with a solid MAC implementation things should be reasonably secure (depending on threat model). I've actually considered trying bubblewrap so I'm using something more simple and thus less likely to have low-hanging exploits (or less likely to expose kernel code with low-hanging exploits).
There was a discussion regarding user namespaces on the Firejail github site. netblue30 wrote: I hope this makes your worries a bit smaller. Note also that user namespaces have advantages if you're using a Chromium-based browser as its Firejail profile can be considerably tightened. The broker process is now much better sandboxed.
Thanks. I remembered reading that somewhere but couldn't find it again I use Firefox and Torbrowser, so as of yet I wouldn't receive as much benefit. I know Chromium has better security on Linux (and everywhere else at this point), but out of principle I will not use it- I think Chromium use contributes to a browser monoculture and that is ultimately a danger to the open internet (what's left of it). Mozilla for all its problems and mistakes is a much better company than Google in terms of freedom. Even if Chromium is open-source, its development and use still helps Google. I look forward to when Firefox reaches security parity with Chromium browsers- things are moving along on that front. For now user.js/ublock/noscript/firejail/MAC etc will have to do... I'm still undecided on whether I should use user namespaces at all for now.
I doubt that this is still true if compared with FF57+. The new FF uses basically the same architecture as Chromium and this also applies to sandboxing. This wiki site shows details and the current status. It's possible, of course, that both browsers might use slightly different rulesets and there might be other subtle differences - but by and large the FF sandbox should be on par with Chromium. And if you run them in Firejail, the differences are even smaller. Note that what I said doesn't apply to the Torbrowser as that one is based on FF ESR (52). Yes, agreed! Ah, yes, I remember that you compile your own kernel. IMO, this issue not so problematic if you're running them in Firejail: Chromium and FF57+ would be running in a user namepace sandbox (provided that the kernel supports that) which in turn is running in a SUID sandbox provided by Firejail. Hence, if there is a problem with the user namespace sandbox this should (hopefully) be mitigated by the SUID sandbox. And, as mentioned above, with the additional benefit that the broker process can be much better confined. I'm not worried
I've never tried it. But there is a Firejail profile for Firefox ESR (which is identical to the Firefox profile) so there should be no problems.
