Default paths as of neovim 0.7.0:

• backupdir: $XDG_DATA_HOME/nvim/backup//
• directory: $XDG_DATA_HOME/nvim/swap//
• undodir: $XDG_DATA_HOME/nvim/undo//
• viewdir: $XDG_DATA_HOME/nvim/view//
• shada file: $XDG_DATA_HOME/nvim/shada/main.shada
• log dir: $XDG_CACHE_HOME/nvim/log

Default paths as of [1]:

• backupdir: $XDG_STATE_HOME/nvim/backup//
• directory: $XDG_STATE_HOME/nvim/swap//
• undodir: $XDG_STATE_HOME/nvim/undo//
• viewdir: $XDG_STATE_HOME/nvim/view//
• shada file: $XDG_STATE_HOME/nvim/shada/main.shada
• log dir: $XDG_STATE_HOME/nvim/log

[1] https://github.com/neovim/neovim/pull/15583

Describe the solution you'd like

choom 123

in the profile will write 123 into /proc/<pid>/oom_score_adj

Additional context

• man 1 choom and man 5 proc
• This should be done unprivileged because writing negative numbers is a privileged task.

Is your feature request related to a problem? Please describe.

By default (kernel default) only blocked syscall are only logged if --seccomp-error-action is kill or log but not Errno(EPERM).

Describe the solution you'd like

Load seccomp filter with syscall(SYS_seccomp, SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, &fl->prog) on supported kernels (>=4.14).

Describe alternatives you've considered

N/A

Additional context

https://man7.org/linux/man-pages/man2/seccomp.2.html

Describe the solution you'd like

choom 123

in the profile will write 123 into /proc/<pid>/oom_score_adj

Additional context

• man 1 choom and man 5 proc
• This should be done unprivileged because writing negative numbers is a privileged task.

I have resurrected firejail-welcome.sh from contrib section (author @rusty-snake), moved it under firecfg with some small modifications. It is a short interactive configuration guide for new users. Run it as:

$ sudo firecfg --guide

The script uses zenity (https://en.wikipedia.org/wiki/Zenity). In case the user doesn't have zenity installed, we redirect the calls to a small program in /usr/lib/firejail that has a similar interface and works in console - I'll bring it up in a few days.

Take a look, bugs, add/remove things, spelling, English etc.

Different versions of electron load flags from different files.

When nogroups is used, the following warning may be issued (potentially multiple times, as drop_privs may be called more than once):

Warning: cleaning all supplementary groups

But the warning is being shown even when it seems that all supplementary groups can be safely dropped (and are thus dropped), which is likely a common scenario. This commit prevents the warning from being printed in that case, making it so that it is only shown in the non-happy paths (as was the case on firejail 0.9.66).

Misc: The added code was copied from drop_privs.

This amends commit 7abce0b4c ("Fix keeping certain groups with nogroups", 2021-11-30) / PR #4732.

Kind of relates to #4930.

I have resurrected firejail-welcome.sh from contrib section (author @rusty-snake), moved it under firecfg with some small modifications. It is a short interactive configuration guide for new users. Run it as:

$ sudo firecfg --guide

The script uses zenity (https://en.wikipedia.org/wiki/Zenity). In case the user doesn't have zenity installed, we redirect the calls to a small program in /usr/lib/firejail that has a similar interface and works in console - I'll bring it up in a few days.

Take a look, bugs, add/remove things, spelling, English etc.

Is your feature request related to a problem? Please describe.

By default (kernel default) only blocked syscall are only logged if --seccomp-error-action is kill or log but not Errno(EPERM).

Describe the solution you'd like

Load seccomp filter with syscall(SYS_seccomp, SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, &fl->prog) on supported kernels (>=4.14).

Describe alternatives you've considered

N/A

Additional context

https://man7.org/linux/man-pages/man2/seccomp.2.html

Is your feature request related to a problem? Please describe.

The following line of text in What is SUID, and how does it affect me could be misleading:

"If you are not using Chromium or a browser based on Chromium (Opera, etc.) turn on force-nonewprivs flag in /etc/firejail/firejail.config file."

I'm informed (by this discussion here: https://github.com/netblue30/firejail/discussions/5106) that Chromium actually works fine with force-nonewprivs yes set. UNLESS you've set kernel.unprivileged_userns_clone=0 or are on one of the very few distros which have it configured like that by default. So for many people there's no reason to be warned off simply because they use Chromium.

Describe the solution you'd like

I don't really know what I'm talking about, but in the interest of trying to be helpful here's how I'd restructure the text.

3. Set force-nonewprivs flag

Turn on force-nonewprivs flag in /etc/firejail/firejail.config file. As root, open the file in a text editor and add this line:

force-nonewprivs yes

The flag prevents rising privileges after the sandbox was started. It is believed to clean most SUID problems that will ever be attributed to Firejail.

Note you should avoid doing this if you use a Chromium-based browser and have set kernel.unprivileged_userns_clone=0 (or are on one of the few distros which do this by default.) Unfortunately, Chromium-based browsers need to rise privileges in order to install their own SUID sandbox.

Describe alternatives you've considered

As previously mentioned I basically don't know what I'm talking about, so consider this with a HUGE handful of salt.

But I'm getting the impression that for most users, setting force-nonewprivs yes provides a slither of extra security with no negative ramifications. So maybe you could just make that the default?

Is your feature request related to a problem? Please describe.

The following line of text in What is SUID, and how does it affect me could be misleading:

"If you are not using Chromium or a browser based on Chromium (Opera, etc.) turn on force-nonewprivs flag in /etc/firejail/firejail.config file."

I'm informed (by this discussion here: https://github.com/netblue30/firejail/discussions/5106) that Chromium actually works fine with force-nonewprivs yes set. UNLESS you've set kernel.unprivileged_userns_clone=0 or are on one of the very few distros which have it configured like that by default. So for many people there's no reason to be warned off simply because they use Chromium.

Describe the solution you'd like

I don't really know what I'm talking about, but in the interest of trying to be helpful here's how I'd restructure the text.

3. Set force-nonewprivs flag

Turn on force-nonewprivs flag in /etc/firejail/firejail.config file. As root, open the file in a text editor and add this line:

force-nonewprivs yes

The flag prevents rising privileges after the sandbox was started. It is believed to clean most SUID problems that will ever be attributed to Firejail.

Note you should avoid doing this if you use a Chromium-based browser and have set kernel.unprivileged_userns_clone=0 (or are on one of the few distros which do this by default.) Unfortunately, Chromium-based browsers need to rise privileges in order to install their own SUID sandbox.

Describe alternatives you've considered

As previously mentioned I basically don't know what I'm talking about, so consider this with a HUGE handful of salt.

But I'm getting the impression that for most users, setting force-nonewprivs yes provides a slither of extra security with no negative ramifications. So maybe you could just make that the default?

Without this change here is what I see in syslog when running for example firejail --profile=ssh /usr/bin/ssh test.local:

Apr  2 14:59:29 kek kernel: [  177.596180] audit: type=1400 audit(1648900769.222:29): apparmor="DENIED" operation="connect" profile="firejail-default" name="/run/avahi-daemon/socket" pid=2562 comm="ssh" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0

So it can't access the socket hence can't resolve the name.