mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #6058] Make whitelist handle symlinks in intermediate path #3169
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#3169
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 @haarp on GitHub (Oct 20, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6058
Discussed in https://github.com/netblue30/firejail/discussions/5980
Hello,
I'm seeing a problem with no easy solution when symlinks are involved.
Conditions:
~/.mozilla/firefox/profiles.ini, but nothing else in~/.mozilla/~/.mozillais a symlink to~/Private/mozillaThe obvious solution is
whitelist ${HOME}/.mozilla/firefox/profiles.ini. whitelist will descend down the path, see the.mozillasymlink and follow it, effectively whitelisting~/Private/mozilla/profiles.ini. But the~/.mozillasymlink, as expected by applications, is missing inside the jail!Naive fix: Add
whitelist ${HOME}/.mozilla. This will create the~/.mozillasymlink. But it'll also whitelist all of~/Private/mozilla/*! Not what we want.I see no way of solving this with the currently available firejail directives. The implicit creation of jail symlinks by
whitelistis not documented, and only works when it points to a symlink directly. From the manpage:Symbolic link handling: Whitelisting a path that is a symbolic link will also whitelist the path that it points to.whitelist. It currently follows symlinks as it descends down the path. Have it also create the symlinks in the jail for each followed link. TBD: Unexpected side effects?mklinkdirective, similar to how there already is amkdirone. Easy fix, but hacky and inelegant.Thanks!
@tolikzinovyev commented on GitHub (Mar 28, 2024):
I ran into the same issue.
@ghost commented on GitHub (Mar 28, 2024):
@haarp
I've revisited your original discussion on this topic earlier today. Think I've found a working set of options for your custom
discord setup. As this issue is not limited to discord I opted to post on that thread.@tolikzinovyev
Can you please elaborate? Are you experiencing similar issues in
discordas the OP? Somewhere else? AFAICT nobody is working on the suggested solutions (yet). It would be helpful if you could share a reproducer or provide some context here.@tolikzinovyev commented on GitHub (Mar 28, 2024):
My troubles are limited to symlinks only. I have a folder
~/Downloads/firefoxwhich I would like to whitelist where~/Downloadsis a symlink to~/.homeextra. However,whitelist ${HOME}/Downloads/firefoxdoesn't create the necessary symlink in sandbox.@ghost commented on GitHub (Mar 28, 2024):
@tolikzinovyev
The firefox-common.profile already whitelists ${DOWNLOADS}:
17684bb087/etc/profile-a-l/firefox-common.profile (L29)How did you (try to) whitelist the symlinked
${HOME}/.homeextraexactly? What happens when you runfirejail --whitelist=~/.homeextra /usr/bin/firefox?@tolikzinovyev commented on GitHub (Mar 28, 2024):
Thanks, but this is not limited to firefox only.
I only have
whitelist ${HOME}/Downloads/firefox. If I dofirejail --whitelist=~/.homeextra /usr/bin/firefox, then all directories in.homeextraare accessible, not onlyDownloads. Oh, sorry,~/Downloadsis a symlink to~/.homeextra/Downloads, not~/.homeextra.@ghost commented on GitHub (Mar 28, 2024):
@tolikzinovyev
All good. Your setup (and issue) is clearer to me now. I'll try to explain the 'logic' I've been using succesfully in situations like these. Feel free to shoot questions where needed. This isn't particularly straightforward, but it can be achieved safely IMO. Here goes.
[protect ~/.homeextra in all profiles]
in
globals.localblacklist ${HOME}/.homeextra
[selectively lift/grant access to ~/.homeextra in specific profile(s)]
(these options apply for both blacklisting/whitelisting profiles)
e.g. in
firefox.localnoblacklist ${HOME}/.homeextra
# rule-of-thumb: allowed paths (via noblacklist) need to be handled
# BEFORE protecting all others sub-dirs (via blacklist globbing)
noblacklist ${HOME}/.homeextra/bar
noblacklist ${HOME}/.homeextra/Downloads
blacklist ${HOME}/.homeextra/*
[extra step for whitelisting profiles only]
# selectively grant access to ~/.homeextra sub-dirs
whitelist ${HOME}/.homeextra/bar
whitelist ${HOME}/.homeextra/Downloads
That's it...
@tolikzinovyev commented on GitHub (Mar 29, 2024):
Thank you. This is a bit safer than what I do: I don't use blacklists here, only a whitelist. However, this doesn't solve the symlink issue. I would like to whitelist
${HOME}/.homeextra/Downloads/firefoxbut also get the path~/Downloads/firefoxto work.@ghost commented on GitHub (Mar 29, 2024):
@tolikzinovyev
How about this?
# tested file layout
######################
~/.homeextra
~/.homeextra/Downloads
~/.homeextra/hide-me
~/Downloads -> /home/foo/.homeextra/Downloads
~/Downloads/firefox
~/Downloads/hide-me
######################
noblacklist ${HOME}/Downloads
noblacklist ${HOME}/Downloads/firefox
blacklist ${HOME}/Downloads/*
whitelist ${HOME}/Downloads
whitelist ${HOME}/.homeextra/Downloads
@tolikzinovyev commented on GitHub (Mar 29, 2024):
Thank you for the suggestion. I see two problems with it.
~/Downloads/while the sandbox is running will be accessible in the sandbox.~/Downloads/is accessible in the sandbox.@ghost commented on GitHub (Mar 29, 2024):
Correct. I don't see a way around that when symlinking ~/Downloads to ~/.homeextra/Downloads.
Also correct. This happens in lots of profiles. When file access is actually prohibited IMO that's not much of a security issue. Ideal? No. Highly unsafe? IMO not really.
Very likely there are cleaner/tighter/safer alternatives. If you could elaborate what the intended goal is of having a symlinked ~/Downloads/firefox to another location under ~ this symlink spagetti might be avoided. If the goal is to have a dedicated folder for Firefox to access, maybe you can set it in its prefs? I mean, why not point it directly to
~/.homeextra/Downloads/firefoxand control it via a one-linerwhitelist ~/.homeextra/Downloads/firefox?@tolikzinovyev commented on GitHub (Mar 29, 2024):
Yes, I set the download location to
~/.homeextra/Downloads/firefoxin Firefox settings. It works but other applications like signal-desktop ask the location every time. In the file picker I first have to enable hidden files to display.homeextrawhich is several extra clicks. I'm not saying it breaks my setup, but it is an annoyance.@ghost commented on GitHub (Mar 29, 2024):
The default XDG locations are stored in
~/.config/user-dirs.dirs, which is made read-only in disable-common.inc and part of whitelist-common.inc. So for most GUI profiles that should be accessable without having to touch the profiles. Have you tried setting XDG_DOWNLOAD_DIR="$HOME/.homeextra/Downloads/firefox" in that file yet? Alternatively you could add it to~/.config/gtk-{3,4}.0/bookmarksfor ease-of-use in the file picker.@tolikzinovyev commented on GitHub (Mar 30, 2024):
The bookmarks method worked, thank you!
@tolikzinovyev commented on GitHub (Jun 19, 2024):
I ran into this issue again. Here is the scenario. I browse files with Thunar and open a picture in
~/Downloads/firefoxwitheom(eye of mate). Since ineomprofile I only havewhitelist ${HOME}/Downloads/firefox,eomcan't open the picture. This problem is pretty annoying and a fix would be greatly appreciated!