Firejail: Firejail security features limited with Chromium based browsers?

[Kebron718]

Hello,

I'm fairly new to the Linux world and before that I was using Opera and Firefox with Sandboxie.

Looking at the various profiles I noticed that Chromium based browsers do not use most of the security features enabled in the firefox profile like e.g. seccomp, caps.drop all, nonewprivs, noroot.

I know that Chromium has some sandboxing features included. Is this the reason why these features are not in the profile?

I tried putting seccomp in the chromium profile but the browser window would not open.

I could not find anything specific on that subject in the man pages or on the web. Maybe you could elaborate on the reasons for these differences for less experienced users like me.

Secondly, is it save to say that using 'firejail chromium / chrome / opera' with their profiles not including seccomp, etc. is as secure as using 'firejail firefox'?

Best

Kebron718

[netblue30]

Chromium/Opera/etc are distributed with a similar security sandbox. Some features in Firejail are disabled in order to allow this security sandbox to run - you cannot run both of them.

[nick75e]

I don't trust closed-source software so this is why I use firejail with Chrome even though Opera/Chrome(ium) come with their own sandbox.

Looking at the various profiles I noticed that Chromium based browsers do not use most of the security features enabled in the firefox profile like e.g. seccomp, caps.drop all, nonewprivs, noroot.

I've managed to use Chrome with firejail by disabling its sandbox with google-chrome -no-sandbox command (there must be something similar for Chromium and Opera). Then you can use all the options you mentioned.

P.S.: Opera/Chrome's sandbox can protect you from the internet but what's protecting you from Opera/Chrome, _just saying..._

[requiredregistration]

google chrome and opera are based on chromium (which is open source). the sandbox of chromium uses a few of the same features that are used by firejail for security.

[ncouture]

@netblue30 what do you think of the chrome sandbox?

[netblue30]

Firejail is modeled after the chrome sandbox.

[Futureknows]

So is the bottom line Chromium/Chrome are just as safe without Firejail? Google and trust aren't in the same universe.

[curiosity-seeker]

So is the bottom line Chromium/Chrome are just as safe without Firejail?

No, they aren't. It's important to understand the security architecture of Chromium:

1. There are the renderer processes which are sandboxed using a setuid sandbox or a user namespaces sandbox (depending on which one is available in your distro) and seccomp-bpf. That's why enabling seccomp in the Firejail profile is not possible as it prevents Chromium from launching.
2. However, there is the broker process which is "in broad terms, a privileged controller/supervisor of the activities of the sandboxed processes." The broker process is NOT sandboxed at all!

The renderer processes and the broker process communicate with each other via IPC. That site says:

"Security bugs in IPC can have nasty consequences (file theft, sandbox escapes, remote code execution)."

And here is where Firejail comes into play. If you look at the Chromium profile you'll see that through the included *.inc files many important folders/files are blacklisted. Moreover, the Chromium profile is a whitelisted profile which means that Chromium - specifically the broker process - has only access to the files/folders in your home directory which are explicitly whitelisted. And it contains various more options which tighten the sandbox even more.

So, to cut a long story short: Chromium/Chrome sandboxed with Firejail goes far beyond what Chromium offers by default.

P.S.: @netblue30 _caps.keep sys_chroot,sys_admin works_ for me. Perhaps you or someone else can test this, too, so that we could further harden the profile.

[Fred-Barclay]

@curiosity-seeker Awesome! See 021607388923972fbe9c06bcecdea49422f8d911

[Ferroin]

Just to clarify a bit more:

1. For the things that Chromium and friends sandbox, there is actually marginally better security than Firejail provides. THis is because each renderer, plugin, and extension (the bits that matter) is in it's own private sandbox. So, for example, some arbitrary extension X can't interfere with plugin Y unless explicit permission is granted for it to do so. This is done so that it's much harder to fully hijack a browser or effect phishing attacks.
2. For Chromium as a whole, the sandboxing is worse than what Firejail provides by default, since Firejail better isolates things from the rest of the system, as it doesn't sandbox certain components that can be used to access the rest of the system.

In general, I would suggest to most people that you want to use the firejail profile as-is, because using -no-sandbox and adding seccomp to the firejail profile actually reduces the internal security of the browser.

[curiosity-seeker]

@Ferroin : Absolutely! I had actually planned to write a similar answer to @nick75e 's post but forgot about it.

Regarding your point 1.: This is becoming even more important as the Chromium developers are about to improve site isolation.

[curiosity-seeker]

@Fred-Barclay : Thanks! So this works also for you. Good to know!

[Kebron718]

Hello,

glad to see that there‘s some new life in this thread.

I‘ve been running Chromium on Leap with the following additions to the Chromium profile without any problems:

caps.drop all

protocol unix,inet,inet6,netlink

nonewprivs

noroot

I noticed that using protocol unix,inet,inet6,netlink seems to at least partially enable seccomp in Firejail. At least it says so in Firetools/Tools. By removing the protocol entry it shows seccomp: disabled.

Would it be better security-wise to remove the protocol entry altogether because it might interfere with Chromium’s built-in seccomp sandbox or should I leave it in as an additional layer of security?

PS
I also noticed the entry ipc-namespace in the Firefox profile. Does it make any sense adding it to the Chromium profile as well?

[Ferroin]

@Kebron718 I'm not entirely sure. I believe that the protocols thing uses Seccomp-BPF to do syscall argument inspection to limit what protocols can be used, and I think that coexists fine with further seccomp restrictions, so unless you're seeing error messages about sandboxing from Chromium, I would assume that it doesn't interfere with Chromium's seccomp usage.

As far as IPC-namespace, that may or may not break things. I don't know enough about how Chromium's internal sandboxing is done at a low level to know for certain.

[curiosity-seeker]

@Kebron718 : I must admit that I'm really puzzled! I tried the options you suggested on Fedora 25 - and they work for me! I had tried caps.drop all a long time before and Chrome wouldn't start, that's why I had been using caps.keep sys_chroot,sys_admin for a while. So it seems that something has changed in the inner workings of Chrome.

I can also confirm that after enabling protocol unix,inet,inet6,netlink Firetools reports seccomp as enabled. Very interesting, indeed!

@netblue30: Do you have an explanation for this behavior?

[netblue30]

I noticed that using protocol unix,inet,inet6,netlink seems to at least partially enable seccomp in Firejail. At least it says so in Firetools/Tools. By removing the protocol entry it shows seccomp: disabled.

Yes, protocol statement is implemented as a separate seccomp filter. So, you end up with two seccomp filters installed.

caps.drop all
protocol unix,inet,inet6,netlink
nonewprivs
noroot

Is it possible Suse/Leap people disabled the sandbox embedded in chromium? If that's the case, you should also try to add "seccomp" to your profile.

[Ferroin]

Is it possible Suse/Leap people disabled the sandbox embedded in chromium? If that's the case, you should also try to add "seccomp" to your profile.

New enough versions of the Linux kernel don't require special capabilities (or EUID=0) to create user namespaces, which means that on such kernels, the sandboxing in Chromium/Chrome/etc behaves a bit differently from an outside perspective, and caps.drop all shouldn't prevent the sandboxing from working.. I think that the current kernel shipped in openSUSE Leap has the patches that do this, but I'm not 100% certain about it.

[curiosity-seeker]

Is it possible Suse/Leap people disabled the sandbox embedded in chromium? If that's the case, you should also try to add "seccomp" to your profile.

Well, I'm using Fedora 25 (64bit), and chrome://sandbox reports that the Namespace-Sandbox, the PID-Namespaces, Netwerk-Namespaces and the"Seccomp-BPF"-Sandbox are enabled and that "Seccomp-BPF"-Sandbox supports TSYNC". The SUID-Sandbox and YAMA-LSM are disabled. If I enable seccomp on the profile, Chrome doesn't start. Without seccomp, above options work for me.

[Ferroin]

I'm pretty certain the 'SUID-Sandbox' thing is what Chrome/Chromium reports as enabled when it needs to run SUID root or with CAP_SYS_ADMIN to get the sandboxing working right, which is what I was talking about above that isn't needed on newer Linux kernels.

The YAMA thing you don't need to worry too much about, it's a kernel-side protection that Chrome/Chromium doesn't have any control over, but is unnecessary on most systems that use SELinux (including Fedora) because the SELinux default policies already handle what YAMA protects against (namely, ptrace() based attacks).

As far as seccomp being enabled in firejail breaking Chrome sandboxing, I'm pretty sure Firejail explicitly disables further modification of Seccomp-BPF state.

[Fred-Barclay]

If I'm understanding this correctly, we can add caps.drop all to the Chrome profile in a year or two, after Debian Jessie/Ubuntu 14.04/other distros with older kernels are EOL?

[netblue30]

New enough versions of the Linux kernel don't require special capabilities (or EUID=0) to create user namespaces,

It's been there since kernel 3.10, but very few distros have it enabled by default. Ubuntu and Mint have it by default, in Debian you need to be root to use it, Arch doesn't have it compiled in the kernel.

[curiosity-seeker]

I'm pretty certain the 'SUID-Sandbox' thing is what Chrome/Chromium reports as enabled when it needs to run SUID root or with CAP_SYS_ADMIN to get the sandboxing working right

I think this corresponds to what the Chromium doc says: The setuid is enabled for old kernels (or kernels without above change), the user namespaces sandbox is enabled for new kernels.

@Fred-Barclay : In this respect I guess that we can add this change in a year or two, provided that distros like Arch Linux will have enabled user namespaces by then. So far the Arch developers haven't as they say that there are still too many bugs in user namespaces. Let's hope that this will change over time.

[Fred-Barclay]

@curiosity-seeker That's right - I'd forgotten about Arch. Lack of user namespaces is one reason I haven't stuck with Arch for very long. 😞

[curiosity-seeker]

FWIW, this works for me on Fedora 25 for google-chrome-stable:

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

EDIT: As a matter of fact above seccomp.keep plus seccomp work for me (considering this which I hadn't known before):

[curiosity-seeker]

BTW, is there any reason why disable-develop.inc is not in the profile? I've added it and it doesn't cause any problems so far.