[GH-ISSUE #1255] Modify whitelist's behaviour

gitea-mirror commented

2026-05-05 06:58:51 -06:00

Owner

Originally created by @cryzed on GitHub (Apr 28, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1255

I follow this guide currently to create whitelisted profiles. My profile for PyCharm that uses a whitelist instead of a blacklist looks currently like this:

include ~/.config/firejail/_glassbox.profile

mkdir ~/.PyCharmCE2017.1
mkdir ~/.java
mkdir ~/.virtualenvs
mkfile ~/.gitconfig

whitelist ~/.PyCharmCE2017.1
whitelist ~/.java
whitelist ~/.virtualenvs
whitelist ~/.gitconfig

The first 2 includes basically take care of whitelisting my ~/Documents folder and including the firejail default profile and common whitelist includes. As you see, to make sure that data persists that I create using PyCharm, I make sure to create all directories and files that PyCharm might create before whitelisting them -- if I simply whitelisted them and they don't actually exist they won't survive a reboot as far as I understand.

Now having to do this comes at a slight disadvantage: having to create all possible folders and files that an application might create to make sure they are persistent, might result in many empty directories and files in the home directory where it's not even guaranteed that they have the correct permissions set, assuming the application does something special with them.

Would it be possible to modify the behavior of the whitelist command to simply copy over whitelisted files and folders to the actual home directory if they were created within the whitelisted environment during the execution? That way one wouldn't have to create all the files and folders beforehand on the off-chance that they might be used in that specific scenario and the files and folders would only be created (with the correct permissions), when they would actually be created if the program was running normally.

I know that Firejail uses bind mounts for the whitelisting feature, so I'm not sure how feasible this is -- I could imagine intercepting system calls that create directories and files, checking if they are whitelisted, and then creating them in the home-directory instead and bind mounting them inside the sandbox, that would avoid having to copy the files back to the home directory after the execution. However I don't know if something like this is outside the scope of Firejail or even easily possible, there might be an easier solution that I'm not seeing. However I do think if Firejail was able to do something like this, the whitelist feature would be almost as easy to use as the blacklist feature and be more secure by design.

I would appreciate your thoughts.

Originally created by @cryzed on GitHub (Apr 28, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1255 I follow [this guide](https://firejail.wordpress.com/documentation-2/building-whitelisted-profiles/) currently to create whitelisted profiles. My profile for PyCharm that uses a whitelist instead of a blacklist looks currently like this: ```include ~/.config/firejail/_whitelist-documents.profile include ~/.config/firejail/_glassbox.profile mkdir ~/.PyCharmCE2017.1 mkdir ~/.java mkdir ~/.virtualenvs mkfile ~/.gitconfig whitelist ~/.PyCharmCE2017.1 whitelist ~/.java whitelist ~/.virtualenvs whitelist ~/.gitconfig ``` The first 2 includes basically take care of whitelisting my ~/Documents folder and including the firejail default profile and common whitelist includes. As you see, to make sure that data persists that I create using PyCharm, I make sure to create all directories and files that PyCharm might create before whitelisting them -- if I simply whitelisted them and they don't actually exist they won't survive a reboot as far as I understand. Now having to do this comes at a slight disadvantage: having to create all possible folders and files that an application _might_ create to make sure they are persistent, might result in many empty directories and files in the home directory where it's not even guaranteed that they have the correct permissions set, assuming the application does something special with them. Would it be possible to modify the behavior of the whitelist command to simply copy over whitelisted files and folders to the actual home directory if they were created within the whitelisted environment during the execution? That way one wouldn't have to create all the files and folders beforehand on the off-chance that they might be used in that specific scenario and the files and folders would only be created (with the correct permissions), when they would actually be created if the program was running normally. I know that Firejail uses bind mounts for the whitelisting feature, so I'm not sure how feasible this is -- I could imagine intercepting system calls that create directories and files, checking if they are whitelisted, and then creating them in the home-directory instead and bind mounting them inside the sandbox, that would avoid having to copy the files back to the home directory after the execution. However I don't know if something like this is outside the scope of Firejail or even easily possible, there might be an easier solution that I'm not seeing. However I do think if Firejail was able to do something like this, the whitelist feature would be almost as easy to use as the blacklist feature and be more secure by design. I would appreciate your thoughts.

gitea-mirror

2026-05-05 06:58:51 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:58:57 -06:00

Author

Owner

@netblue30 commented on GitHub (May 1, 2017):

Would it be possible to modify the behavior of the whitelist command to simply copy over whitelisted files and folders to the actual home directory if they were created within the whitelisted environment during the execution?

No, because there is no reliable way to detect when the sandbox is closed in order to copy the files back on the real system.

@netblue30 commented on GitHub (May 1, 2017): > Would it be possible to modify the behavior of the whitelist command to simply copy over whitelisted files and folders to the actual home directory if they were created within the whitelisted environment during the execution? No, because there is no reliable way to detect when the sandbox is closed in order to copy the files back on the real system.

gitea-mirror commented

2026-05-05 06:59:01 -06:00

Author

Owner

@cryzed commented on GitHub (May 2, 2017):

So what about using the existing --trace feature's functionality to do what I suggested here:

I could imagine intercepting system calls that create directories and files, checking if they are whitelisted, and then creating them in the [(real) whitelisted directory] instead and bind mounting them inside the sandbox, that would avoid having to copy the files back to the home directory after the execution.

Then there would be no need to detect if the sandbox was closed.

@cryzed commented on GitHub (May 2, 2017): So what about using the existing `--trace` feature's functionality to do what I suggested here: > I could imagine intercepting system calls that create directories and files, checking if they are whitelisted, and then creating them in the [(real) whitelisted directory] instead and bind mounting them inside the sandbox, that would avoid having to copy the files back to the home directory after the execution. Then there would be no need to detect if the sandbox was closed.

gitea-mirror commented

2026-05-05 06:59:01 -06:00

Author

Owner

@SYN-cook commented on GitHub (May 3, 2017):

the whitelist feature would be almost as easy to use as the blacklist feature and be more secure by design

But the fact that non-whitelisted files are discarded when the jail is closed adds significantly to the security of whitelisting... it is in fact the unique selling point of whitelisting. When you take that away, there is not much difference any more between whitelisting and what you can achieve with blacklisting.

Also blacklisting is not much less convenient if you consequently employ wildcards, something that whitelisting doesn't support as of now. Take only your example profile:

include ~/.config/firejail/_glassbox.profile #you would need to rewrite this
noblacklist ~/.PyCharmCE2017.1
noblacklist ~/.java
noblacklist ~/.virtualenvs
noblacklist ~/.gitconfig
blacklist   ~/*

The include file might have to be a bit longer, but the actual profile is short and crisp, and whitelisting wouldn't make it much shorter.

@SYN-cook commented on GitHub (May 3, 2017): > the whitelist feature would be almost as easy to use as the blacklist feature and be more secure by design But the fact that non-whitelisted files are discarded when the jail is closed adds significantly to the security of whitelisting... it is in fact the unique selling point of whitelisting. When you take that away, there is not much difference any more between whitelisting and what you can achieve with blacklisting. Also blacklisting is not much less convenient if you consequently employ wildcards, something that whitelisting doesn't support as of now. Take only your example profile: ``` include ~/.config/firejail/_glassbox.profile #you would need to rewrite this noblacklist ~/.PyCharmCE2017.1 noblacklist ~/.java noblacklist ~/.virtualenvs noblacklist ~/.gitconfig blacklist ~/* ``` The include file might have to be a bit longer, but the actual profile is short and crisp, and whitelisting wouldn't make it much shorter.

gitea-mirror commented

2026-05-05 06:59:02 -06:00

Author

Owner

@cryzed commented on GitHub (May 3, 2017):

The reason I prefer to use whitelist is because blacklist simply denies the access to files and folders, while whitelist completely hides them.

@cryzed commented on GitHub (May 3, 2017): The reason I prefer to use `whitelist` is because `blacklist` simply denies the access to files and folders, while `whitelist` completely hides them.

gitea-mirror commented

2026-05-05 06:59:03 -06:00

Author

Owner

@SYN-cook commented on GitHub (May 3, 2017):

Ok, thanks. I understand. So the use case is hiding filenames in directories that need to be accessed... but without having to create files and folders first, as would be necessary with current whitelisting

@SYN-cook commented on GitHub (May 3, 2017): Ok, thanks. I understand. So the use case is hiding filenames in directories that need to be accessed... but without having to create files and folders first, as would be necessary with current whitelisting

gitea-mirror commented

2026-05-05 06:59:04 -06:00

Author

Owner

@cryzed commented on GitHub (May 6, 2017):

That seems pretty accurate yes. It's simply an additional layer of privacy. It is always possible to expose something accidentally within a file or folder-name that you really didn't want to -- hiding files and folders that really don't need to be accessed seems like a good idea in general. Whitelisting allows me to do that currently, with this (small) drawback and I had hoped to eliminate it.

@cryzed commented on GitHub (May 6, 2017): That seems pretty accurate yes. It's simply an additional layer of privacy. It is always possible to expose something accidentally within a file or folder-name that you really didn't want to -- hiding files and folders that really don't need to be accessed seems like a good idea in general. Whitelisting allows me to do that currently, with this (small) drawback and I had hoped to eliminate it.

gitea-mirror commented

2026-05-05 06:59:06 -06:00

Author

Owner

@jody-frankowski commented on GitHub (May 18, 2017):

I was about to make an issue about that. It would be nice to have an option in firejail ("--whitelist-mkdir"?) that would tell firejail to create whitelisted directories.

@jody-frankowski commented on GitHub (May 18, 2017): I was about to make an issue about that. It would be nice to have an option in firejail ("--whitelist-mkdir"?) that would tell firejail to create whitelisted directories.

gitea-mirror referenced this issue

2026-05-05 10:07:35 -06:00

[PR #854] [MERGED] new profiles #3771

Rows
Columns

[GH-ISSUE #1255] Modify whitelist's behaviour #854