This is intentional and the purpose of sandboxing.
I use firejail with Firefox and the Download directory is the only directory that firejail let the browser to have access to.
If you need to “relax” firejail a bit, you need to modify the relevant profile to be more permissive.
Firejail uses profiles to set the security protections for each of the applications executed inside of it - you can find the default profiles in /etc/firejail/application.profile. Should you require custom profiles for applications not included, or wish to modify the defaults, you may place new rules or copies of the defaults in the ~/.config/firejail directory. You may have multiple custom profile files for a single application, and you may share the same profile file among several applications.
For example, in your case, you need to configure the profile to access the directory where you store your PDF files.
I wonder if that happens all by itself if you don’t run the command I referred to above to integrate firejail with apparmor.
Enable AppArmor support
Since 0.9.60-1, Firejail has supported more direct integration with AppArmor through a generic AppArmor profile. During installation, the profile, firejail-default, is placed in /etc/apparmor.d directory, and needs to be loaded into the kernel by running the following command as root:
I can’t remember if I did it manually or it was default. Even if I did it manually it might be somewhere explaining how to get the default firejail to work and suggested to do this.
years ago, firejail.
great idea on paper.
no browser worked.
lot of hassle.
too naive and noob at the time to use tools and make rules.
colossal PITA. never looked back, will never return–other ways to skin a cat
With AppArmor not enabled, I’m still able to use firejail, even with the apparmor directive enabled in my application profile, it’ll just throw a warning. To get rid of the warning, I can comment out (or delete) the apparmor line in that applications profile: (not a full profile, just a snippet)
...
# kernel
seccomp
nonewprivs
caps.drop all
noroot
#apparmor
I went through the process of enabling AppArmor today. I’m using Grub, so the process looked like this:
Edit /etc/default/grub, and add the following kernel parameter (reference) to the end of the existing GRUB_CMDLINE_LINUX_DEFAULT='' variable:
lsm=landlock,lockdown,yama,integrity,apparmor,bpf
After saving that, run this to install the config:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Then reboot. Test AppArmor is active by running (should output Yes):
Creating desktop files was never the problem(I know alacarte), it was just annoying that for some applications you had to create a separate way of making firejail work, instead of just using the firejail command which worked for most applications. The other things I mentioned about firejail were more of problem.
But it’s been a while that was what I remember of it.
This sentiment, as well as @drunkenvicar’s inspired Haiku, are relatable takes. I was able to get firejail behaving for the most part with my browsers (with a useful pointer from @BluishHumility), but was hitting walls everywhere else.
It is by default, very restrictive to the point of breaking many things. I didn’t find much success using the firejail --build someapp command, as the offered profiles were full of highly specific complexity, and still didn’t work.
firetools was a game changer though. So far, the profiles I’m getting from it are simple and easy to adjust, and my applications work. Within minutes, I was up and running and spitting out profiles for the applications that didn’t work well with the defaults, and now have firejail set as default (sudo firecfg).
My main concern at the moment, is it was a little too easy. Are my profiles not providing enough protection? I’m still working that one out.
Wont it make sense for firejail to create its own temporary user profile which is discarded the moment the browser is closed? That way the browser or its add-ons do not interact with any of user directories. Thus creating an effective sandbox. Giving access to ${DOWNLOADS} directory might be an escape route, for any malicious code/actor to access the system.
Oh @Bink I wish I read this a bit earlier. I uninstalled both AppArmor and FireJail.
But I may try again on another install perhaps in the coming few days.
How did you do it? Simple step by step. What is making me feel lost is that I understand that firejail require AppArmor, this is why there is this other one (the orphaned compiled without AppArmor. Maybe perhaps it is orphaned because the “standard” firejail now can work with it disabled.
Step by step guide please, I may retry in a few days.
--private
Mount new /root and /home/user directories in temporary filesystems. All modifications are discarded when the sandbox is closed.
Example:
$ firejail --private firefox
Yep. A true sandbox. Allowing access to system resources is prevented. Ideally I would like to have fake Audio and Display too, not the actual one, with fake hardware specs. This way even Audio fingerprinting as well as Display fingerprinting are rendered useless. When this is coupled with VPN that will truly give some decent level of anonymity as well as protection.
Excuse me for being so illiterate.
For my humble non techie mind these 2 sentences seem contradictory to me.
how is it a dependency, and how it doesn’t require apparmor to be enabled, or "firejail being integrated into apparmor.
I understand. That may seem contradictory that the package A require package B as its dependency but it can be used without the “services” the the package B provides.
In the case of firejail, two specific steps must be taken by the user to integrate firejail into apparmor.
Step One: if you use GRUB
And: sudo systemctl enable apparmor.service
Reboot.
Step Two:
Now you can use firejail with its profiles integrated into apparmor.
Without these specific steps, you can just use firejail.
There is also another possibility: using apparmor alone.
You can only install the package apparmor and enable it according to the step one above.
I hope I’ve got it right (if not I hope that the experts correct me) and this dissipates some of your doubts.
If firejail can be used with AppArmor and both of them have profiles defined, then which profile is used?
Is it firejail profile only? Or is it AppArmor profile only? Or is it both? If both what takes precedence, firejail’s profile or apparmor profile?
If both the profiles are active, when firejail is used in conjunction with apparmor, and there is a conflict between these profiles then what takes precedence?
By conflict I mean, that firejail permits one thing while apparmor does not permit it or vice versa. For example if apparmor restricts the use of CAP_SYS_ADMIN capability while firejail permits it then what happens?
, are relatable takes. I was able to get 