[GH-ISSUE #554] Firejail security features limited with Chromium based browsers?

gitea-mirror commented

2026-05-05 05:45:11 -06:00

Owner

Originally created by @Kebron718 on GitHub (Jun 2, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/554

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

Originally created by @Kebron718 on GitHub (Jun 2, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/554 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

gitea-mirror

2026-05-05 05:45:11 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:45:16 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 2, 2016):

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.

@netblue30 commented on GitHub (Jun 2, 2016): 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.

gitea-mirror commented

2026-05-05 05:45:18 -06:00

Author

Owner

@nick75e commented on GitHub (Jun 2, 2016):

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...

@nick75e commented on GitHub (Jun 2, 2016): 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..._

gitea-mirror commented

2026-05-05 05:45:20 -06:00

Author

Owner

@requiredregistration commented on GitHub (Jun 3, 2016):

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.

@requiredregistration commented on GitHub (Jun 3, 2016): 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.

gitea-mirror commented

2026-05-05 05:45:24 -06:00

Author

Owner

@ncouture commented on GitHub (Sep 3, 2016):

@netblue30 what do you think of the chrome sandbox?

@ncouture commented on GitHub (Sep 3, 2016): @netblue30 what do you think of the chrome sandbox?

gitea-mirror commented

2026-05-05 05:45:26 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 3, 2016):

Firejail is modeled after the chrome sandbox.

@netblue30 commented on GitHub (Sep 3, 2016): Firejail is modeled after the chrome sandbox.

gitea-mirror commented

2026-05-05 05:45:28 -06:00

Author

Owner

@Futureknows commented on GitHub (May 22, 2017):

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

@Futureknows commented on GitHub (May 22, 2017): So is the bottom line Chromium/Chrome are just as safe without Firejail? Google and trust aren't in the same universe.

gitea-mirror commented

2026-05-05 05:45:31 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 22, 2017):

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:

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.
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.

@curiosity-seeker commented on GitHub (May 22, 2017): > 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](https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md) of Chromium: 1. There are the renderer processes which are [sandboxed](https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md) 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]([https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md#The-broker-process]) "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](https://www.chromium.org/developers/design-documents/inter-process-communication). That site [says](https://www.chromium.org/developers/design-documents/inter-process-communication#Security_considerations): "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](https://firejail.wordpress.com/documentation-2/building-whitelisted-profiles/) 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.

gitea-mirror commented

2026-05-05 05:45:35 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (May 22, 2017):

@curiosity-seeker Awesome! See 0216073889

@Fred-Barclay commented on GitHub (May 22, 2017): @curiosity-seeker Awesome! See 021607388923972fbe9c06bcecdea49422f8d911

gitea-mirror commented

2026-05-05 05:45:40 -06:00

Author

Owner

@Ferroin commented on GitHub (May 23, 2017):

Just to clarify a bit more:

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.
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.

@Ferroin commented on GitHub (May 23, 2017): 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.

gitea-mirror commented

2026-05-05 05:45:44 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 23, 2017):

@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 commented on GitHub (May 23, 2017): @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](http://www.chromium.org/developers/design-documents/site-isolation).

gitea-mirror commented

2026-05-05 05:45:48 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 23, 2017):

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

@curiosity-seeker commented on GitHub (May 23, 2017): @Fred-Barclay : Thanks! So this works also for you. Good to know!

gitea-mirror commented

2026-05-05 05:45:51 -06:00

Author

Owner

@Kebron718 commented on GitHub (May 23, 2017):

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?

@Kebron718 commented on GitHub (May 23, 2017): 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?

gitea-mirror commented

2026-05-05 05:45:53 -06:00

Author

Owner

@Ferroin commented on GitHub (May 23, 2017):

@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.

@Ferroin commented on GitHub (May 23, 2017): @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.

gitea-mirror commented

2026-05-05 05:45:55 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 25, 2017):

@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?

@curiosity-seeker commented on GitHub (May 25, 2017): @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?

gitea-mirror commented

2026-05-05 05:45:56 -06:00

Author

Owner

@netblue30 commented on GitHub (May 26, 2017):

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.

@netblue30 commented on GitHub (May 26, 2017): > 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.

gitea-mirror commented

2026-05-05 05:45:58 -06:00

Author

Owner

@Ferroin commented on GitHub (May 26, 2017):

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.

@Ferroin commented on GitHub (May 26, 2017): >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.

gitea-mirror commented

2026-05-05 05:45:59 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 26, 2017):

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.

@curiosity-seeker commented on GitHub (May 26, 2017): > 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.

gitea-mirror commented

2026-05-05 05:46:00 -06:00

Author

Owner

@Ferroin commented on GitHub (May 26, 2017):

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.

@Ferroin commented on GitHub (May 26, 2017): 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.

gitea-mirror commented

2026-05-05 05:46:02 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (May 26, 2017):

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?

@Fred-Barclay commented on GitHub (May 26, 2017): 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?

gitea-mirror commented

2026-05-05 05:46:05 -06:00

Author

Owner

@netblue30 commented on GitHub (May 27, 2017):

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.

@netblue30 commented on GitHub (May 27, 2017): > 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.

gitea-mirror commented

2026-05-05 05:46:06 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (May 27, 2017):

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.

@curiosity-seeker commented on GitHub (May 27, 2017): > 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](https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md) 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](https://bugs.archlinux.org/task/36969) that there are [still](https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html) too many bugs in user namespaces. Let's hope that this will change over time.

gitea-mirror commented

2026-05-05 05:46:08 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (May 27, 2017):

@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. 😞

@Fred-Barclay commented on GitHub (May 27, 2017): @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. 😞

gitea-mirror commented

2026-05-05 05:46:12 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jun 1, 2017):

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 commented on GitHub (Jun 1, 2017): 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](https://github.com/netblue30/firejail/issues/1323#issuecomment-305469136) which I hadn't known before):

gitea-mirror commented

2026-05-05 05:46:15 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jun 2, 2017):

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.

@curiosity-seeker commented on GitHub (Jun 2, 2017): 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.

Rows
Columns

[GH-ISSUE #554] Firejail security features limited with Chromium based browsers? #390