Closed eevee closed 6 years ago
I started adding support for it. So far I have: private-dev, private-tmp and whitelist support for --overlay and --chroot sandboxes. You can try it out.
Support for --private=dir and --private-home is coming soon.
whitelist support for --overlay and --chroot sandboxes. You can try it out.
Do I need the latest master because it doesn't seem to work.
Yes, it is only in master. Also, there are some more general fixes related to overlay there. It will go into the next release.
What's the status for whitelist support for --private now?
Also hoping for this feature! I use firejail as a Firefox profile template engine. For each of my customers the customer-template jail from a fully configured Firefox is copied to "customer-n", which then should be used for customer stuff (--private=customer-n). However I'd like to access e.g. downloads with other applications and this leads to problems as I cannot whitelist paths outside of the jail. Also copying from within the jailed Firefox is not possible as long as I can't whitelist my home/x/Desktop path.
Perhaps it's not complete solution for you but it's possible to transfer files from/to --private
sandbox with --get
/--put
options. See FILE TRANSFER
section in manpage.
Thank you for your suggestion, I read through it!
I know that's not really the point of a private "jail", but I'd like to be able to download something in the jailed Firefox and then move it to a folder that's shared with the jail via drag and drop. This is the most comforty option. Put and get are demanding to much effort as I could also then just open Nemo and dragNdrop the files or folders from the jail home/downloads folder.
@H8to I actually have a similar system for so-called "ephemeral profiles". The script is in my Firejail Profiles repo and is called firefox.common
. If you don't want firefox
to be able to access other profiles, you can just use a --whitelist
command to whitelist only that specific profile instead of whitelisting ~/.mozilla/firefox
[edit: the script does this by default now!]. You could probably adapt a simpler version of the script for your use.
Also making --whitelist
compatible with --private
is not that easy. Currently --private
can be used on top of any existent profile and it always give you separated and temporary $HOME
regardless of what rules specific profile contains. If we make it compatible then suddenly all --whitelist
rules existent in profile will take effect which make --private
not effective. Perhaps separated option like --private-whitelist
may be used if anything to no break existing usage.
To add to that, more fundamentally, a "private" jail is not meant to share data with other jails or the host. That's the whole point of a private jail. It's basically meant to act as a chroot for your home directory (which can be set-up by a regular user). If you want to share data, you're probably better off figuring out a solution with whitelist
and scripts (such as the firefox.common
script I alluded to in my previous reply).
Yeah, I fully agree. Should we close this as wontfix? :smile:
@Vincent43 Let's close it for now. If it seems like there is a legimate reason to reconsider it, we'll re-open it.
I'm not sure I understand the reasoning for the wontfix here.
In my case, I'm using a firejailed Firefox browser profile for my work. Using --private=~/work is super useful, as it allows me to have a persistent Firefox browser profile setup, while isolating the browser from everything outside the work directory. However, I have a large number of media files in a directory on a separate HDD that I'd like to be able to regularly access from this Firefox profile. Being able to simply whitelist the desired media directory so I could access it would be enormously useful.
Please consider somehow adding this functionality.
To follow up on my last post; it turns out it actually is possible to do this by whitelisting the media directory in a custom firejail profile. But whitelisting the same directory with --whitelist does not work.
So including whitelist /media/<username>/work_media
in a custom firejail profile works, even when launching with --private=~/work
But launching with --whitelist=/media/<username>/work_media
does not.
Is there a reason for this inconsistency, or is this a bug?
@modelfe --private
"breaks" whitelist
ing only in $HOME.
Is there a reason for this inconsistency, or is this a bug?
If you for example run firejail --whitelist=/media/<username>/work_media firefox
, firejail will load the firejail profile which contains disable-mnt
. disable-mnt
blacklist
s /mnt
, /media
, ... .You can try adding --noprofile
or --ignore=disable-mnt
.
I'd like to voice support for this feature.
One of my use cases is that I use firejail with Steam. As Steam seems to clutter the home directory more than any other program, I've given it its own firejailed home. That way Steam can do whatever it wants to, and all the clutter is out of my way in a separate directory. However, this limits some of the features. For example, I would still like Steam to be able to create desktop shortcuts, but for this to work, it needs access to /usr/share/applications and /usr/share/icons in the real home directory. Ideally, I would like it to have a firejailed home for all directories except those.
The same argument goes for some proprietary video editing software (Davinci Resolve in my case). I want to give it its own home directory to not clutter my personal home, but it obviously still needs access to my Video directory. And I can't just use regular whitelists without private mode, because the files it creates are still important for functionality. I just want to avoid unnecessary clutter in my home directory while still sharing a few important directories with the firejailed application.
I like Vincent43s suggestion of a separate whitelist to not break existing functionality. In any case, not being able to share some directories between the personal home and the firejail home is limiting some functionality.
I need this feature too. A separate permanent home for the app, with some folders of the user home accessible. As a workaround, mount --bind serves this purpose, but requires root password to run every time launching the app and raises some security concern.
An option like --private-whitelist
has legit use cases (see comments above).
Please consider to reopen this bug/feature request.
With
--private=DIR
, I can replace my entire home directory with a persistent substitute. With--whitelist=DIR
, I can preserve part of my home directory while hiding everything else. But there doesn't seem to be any way to combine these behaviors — e.g., if I want to run a game (which needs all its data files to exist) and still let it write out a save file to some undocumented place elsewhere in my home directory.This is also troublesome for writing a flexible general-purpose profile. If I put
private
in the profile, then I can't use--whitelist
on the command line at all; if I don't putprivate
in the profile, then if I don't use--whitelist
on the command line my entire home directory remains exposed.In general it would be nice if
--private
,--whitelist
, and--overlay
had clearer interactions with each other.