mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #7132] can't disable blacklist of ~/.config/firejail #3497
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3497
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @carlsampurna on GitHub (Apr 10, 2026).
Original GitHub issue: https://github.com/netblue30/firejail/issues/7132
Description
firejail calls disable_config() if not running as root, which blacklists ~/.config/firejail. There is no way to tell firejail not to do this, which means when I sandbox a program to back up my home directory, my firejail configs don't get backed up.
Steps to Reproduce
run from your home directory:
$ firejail --noprofile ls -ld .config/firejail
firejail version 0.9.80
Parent pid 2765731, child pid 2765732
Base filesystem installed in 0.05 ms
Child process initialized in 18.53 ms
dr-------- 2 root root 40 Mar 30 09:24 .config/firejail
Parent is shutting down, bye...
Expected behavior
I did not expect the firejail source to contain hardcoded blacklists that cannot be disabled, though from the many calls to disable_file() in fs.c this is only one of many, and as far as I can tell this is undocumented behavior.
Environment
Arch
Linux 6.19.10-zen1-1-zen x86_64
firejail 0.9.80-1
Checklist
firejail /usr/bin/vlcinstead offirejail vlc; seehttps://github.com/netblue30/firejail/issues/2877)/usr/bin/vlc) "fixes" it).Log
Output of
LC_ALL=C firejail --debug /path/to/program@haplo commented on GitHub (Apr 13, 2026):
I don't know whether it will make a difference, but have you tried
/usr/bin/lsinstead of justls?@carlsampurna commented on GitHub (Apr 13, 2026):
produces the same result:
$ firejail --noprofile /usr/bin/ls -ld .config/firejail
firejail version 0.9.80
Parent pid 101929, child pid 101930
Base filesystem installed in 0.05 ms
Child process initialized in 19.21 ms
dr-------- 2 root root 40 Mar 30 09:24 .config/firejail
Parent is shutting down, bye...
@rusty-snake commented on GitHub (Apr 13, 2026):
A sandbox that can modify its own policy is ... well, think of it.
BTW, what's the purpose of sandboxing a backupprogram. It can access all your files, manipulate your backups. It's likely part of your TCB, isn't it?
@carlsampurna commented on GitHub (Apr 13, 2026):
of course, but there's been no suggestion of that. My point is more that firejail shouldn't have any policies compiled in, that can't be disabled. As default behavior it makes sense to blacklist ~/.config/firejail but I should be able to override that with:
noblacklist ~/.config/firejail
read-only ~/.config/firejail
if I want to.
Additionally, all compiled-in policy should be documented outside of the source. If it were all moved to something like /etc/firejail/default_policy.inc then it would be more visible, and all the normal override mechanism would apply.
that's what I thought at first too, but I later realized that my backup program doesn't need network acccess, or device access, or write access to my home directory, etc. Obviously a malicious backup program is still a big problem, but sandboxing it will substantially reduce the available attack surface, and if its malicious behavior is implemented assuming no sandboxing, maybe I win... :)
@Changaco commented on GitHub (Apr 13, 2026):
For what it's worth, I agree that hardcoded blacklisting is a problem.
The workaround is to use another sandboxing tool like bubblewrap or nsjail.
@rusty-snake commented on GitHub (Apr 13, 2026):
Some very basic policies are required to have a privileged escape vulnerability.
Some of the built-in policies can be overriden, see https://github.com/netblue30/firejail/blob/master/etc/profile-m-z/noprofile.profile. Which is also the best "documentation" of these built-in policies.
Beside the problem that you can create
~/.config/firejailif it does not exist, changing the built-in to read-only makes sense to me./etc/firejailisn't blacklisted either.I'm unsure how to interpret this. If it means reduced attack surface for a malicious process to take over control of you backup program, then no, sandboxing can even increase this risk. If it is the attack surface from the backup program to your system, then is a sandbox that can be escaped only a sandbox that provides save-my-ass-security ("if its malicious behavior is implemented assuming no sandboxing").
I would even go a step further and say that firejail might not be the best tool if you want fine control over your sandboxing policy. Firejail has more focus on convenience for GUI programs.
bubblejail and nsjail where already named, then there is minijail, plain
unshare,setprivandsystemd-run.FWIW: My current backup setup (with
restic) uses a systemd unit. This way I can run restic unprivileged but withCAP_DAC_READ_SEARCHand with limited system (write filesystem, network, ...) access.@carlsampurna commented on GitHub (Apr 13, 2026):
the page at that link made me realize that "--noprofile" and "--profile=noprofile" are not the same, ugh.
that points to another, more serious, bug; if ~/.config/firejail doesn't exist the compiled-in blacklist of it apparently fails, and a sandboxed program can then create it.
thanks for the pointers, that's probably good advice; I wish I'd heard it before spending as much time with firejail as I have...
@rusty-snake commented on GitHub (Apr 13, 2026):
Yeah, I know. If its doesn't exist a sandboxed program (that does not use whitelisting) can create
.bashrc,.bash_profile,.bash_login,.bashrc.d,.config/alacritty,.config/systemd,.local/bin,.config/nvim,.gnupg/gpg.conf,.ssh/config,.tmux.conf, ...@Changaco commented on GitHub (Apr 15, 2026):
Is there a dedicated issue for this known firejail vulnerability that lets a program escape the sandbox on its second run?
@OndrejMalek commented on GitHub (Apr 17, 2026):
As workaround I am using for developing profiles with codding assistants:
+1 vote for make it optional and add message about it to terminal. I see its noted in --debug output. There couldbe --verbose logging...