Replies: 4 comments 9 replies
-
Open a feature request for it (and then open a PR with the implementation 😉 ). For scripting, something like that should be possible: #!/bin/bash
if [[ $ENVCLEARED != true ]]; then
exec env -i ENVCLEARED=true HOME="$HOME" USER="$USER" DISPLAY="$DISPLAY" /bin/bash "$@"
fi |
Beta Was this translation helpful? Give feedback.
-
Yes. Why do you want to blacklist everything?
You can not. Once blacklisted it is blacklisted forever. However you can exclude paths from being blacklisted like
So how long is the list of blacklisted stuff?
But you can strip it after the glob, see above.
You don't completely misunderstand it but it is way to complex and unintuitive for new users.
Depends (see also #3041). Think of black and whitelising as two independent things. There is no code in firejail that links them together, only the kernel does it if you apply both to the same paths, like How blacklisting does work. When a file is accessible from the blacklisting PoV.flowchart LR
A{Next Command} -->|noblacklist| B
B(Push the path to the list of paths that should not be blacklisted.) --> A
A -->|blacklist| C
C(Expand globbing) --> D
D{Does this path match any entry in the noblacklist-list?} -->|Yes| A
D -->|No| E(blacklist it now) --> A
This means a file is accessible from the blacklisting PoV if
How whitelisting does work. When a file is accessible from the whitelisting PoV.First of, whitelisting is opt-in. whitelist has something called top-directory. The following top-directories are defined: So a file is accessible from the whitelisting PoV if
|
Beta Was this translation helpful? Give feedback.
-
If you want that, is firejail the right tool for you? Firejail has a |
Beta Was this translation helpful? Give feedback.
-
The problem is compatibility. What when you get a new kind for permission, like
Agree and Disagree. From a technical PoV you are absolutely right (in 90% of the cases). However if it is to tricky (see above) you will end up with no security because
therefore you sometimes have to go with less security than technical possible so you get more security in the end. |
Beta Was this translation helpful? Give feedback.
-
As someone who just started using firejail I had quite a few problems. The biggest issue I have is there is no "secure by default" mode, where the profile could start with zero permissions and gradually add to them. By zero permissions I mean something like a container or VM, where the only mounted filesystems are tmpfs, all required files to run are made from scratch (not copied from the host which could expose the host's identity in the sandbox, which is how it currently works for a lot of files in /etc: passwd, resolv.conf,...), there is no network, the host's username and environment are not copied in, and so on.
filesystem
Regarding blacklist specifically, I found that
blacklist /*
breaks everything, because blacklist seems to be processed as the last step when building the filesystem, so even any mounts and directories created by firejail itself (for example private-etc, private-bin, private-lib,...) are blacklisted and return "permission denied" inside the sandbox. I could not figure out how to "unblacklist" only specific directories after ablacklist /*
- I tried noblacklist, whitelist, did not work, so I had to create a long list of blacklist directives that specifically excluded things like: /tmp, /dev, /bin, /sbin, /usr/lib, /usr/lib64, /lib, /lib64, /home, /proc. This is made worse by the fact that blacklist only supports basic globbing and so you cannot exclude just one directory from the glob/usr/*
: I wanted to not blacklist /usr/share or /usr/lib, so I had to separately blacklist these:/usr/[a-k]* /usr/[m-r]* /usr/s[br]* /usr/[t-z]*
. Maybe I am completely misunderstanding how blacklist, whitelist, noblacklist, ignore blacklist work, but I could not figure out any other way. And in order to make a file accessible, not blacklisting is not enough, it also has to be whitelisted? Not blacklisting it and not whitelisting it does not make it accessible if I understand correctly?private-lib
If you specify a path to a lib file, firejail will put the file directly into /lib, it will not recreate the original path components (for example:
private-lib my/libexample.so
will put it in/lib/libexample.so
even though it was in/lib/my/example.so
.). This breaks some programs that are hardcoded to search in a particular path. If you specify a directory, the directory is recreated with all its contents, for exampleprivate-lib my
. This works around the previous problem but then you can't select just one lib file inside a directory because it will copy all of them.In combination with private-bin it does not find all libraries binaries depend on. In my case it did not find libstdc++.so.6 and libgcc_s.so.1, which I found a lot of issues here saying the same thing. Seems like a bug. (it also did not find libatomic.so or libGL.so)
private-bin
It does not work on /usr/libexec. For example /usr/libexec/webkit2gtk-4.1 which contains binaries for webkit-gtk. So you have to whitelist the path manually. This means private-lib will not automatically find the libraries those binaries depend on so you have to add them by hand to private-lib. Ideally it would also work on and create /usr/libexec inside the sandbox (preserve the full path as it is on the host, in case something expects a hardcoded path to those binaries) and allow private-lib to find libraries those binaries depend on.
rmenv, env
There's no way to clear all environment from the host, for example just
rmenv
could clear all host environment.env
could then work like this:env HOME
would copy HOME from the host into the sandbox. (no need for fixed assignment).I worked around this by copying
env
andsh
executables into the sandbox and executing a shell script like so:sh -c 'env -i HOME="$HOME" USER="$USER" DISPLAY="$DISPLAY" command'
which is ugly.env -i
unsets all environment except that set by its arguments, but only for the executed command passed as arguments. I have not found a simple way to unset all env variables for the entire shell script (shellunset
does not have a "unset all" mode).add a random username function
Currently the host's username is copied into the sandbox. This is identifying information, it should be possible to have a feature that randomizes the username, or even better uses a very common username, for example 'ubuntu'. It would also need to work with
private
in order to change the home directory name, and set environment variables accordingly.In general I think it is better to always write default behavior to be as secure as possible, even if it makes creating custom profiles more tedious because every single thing must be specifically allowed - that is much better than having a default to allow and having to disallow access to a list. I don't think it would be such a problem to hinder functionality or ease of use. Ease of use and security are roughly inversely proportionate to one another.
Beta Was this translation helpful? Give feedback.
All reactions