[GH-ISSUE #2070] [Proposal] Convert all profiles to a whitelist model

gitea-mirror commented

2026-05-05 08:03:30 -06:00

Owner

Originally created by @chiraag-nataraj on GitHub (Jul 28, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2070

I really think we should move towards a whitelist model for profiles, at least by default. In most cases, it's very clear which directories need to be whitelisted, and in cases where it's not, we can stick to the current blacklist-based model. What do people think? I'm willing to sit down and convert many of them (I already have a bunch in my repo, which should help), but I don't want to do it if we decide that it's not a good idea to do this at this time.

Originally created by @chiraag-nataraj on GitHub (Jul 28, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2070 I really think we should move towards a whitelist model for profiles, at least by default. In most cases, it's very clear which directories need to be whitelisted, and in cases where it's not, we can stick to the current blacklist-based model. What do people think? I'm willing to sit down and convert many of them (I already have a bunch in my repo, which should help), but I don't want to do it if we decide that it's not a good idea to do this at this time.

gitea-mirror

2026-05-05 08:03:30 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:03:34 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 28, 2018):

We discussed this a while ago, nearly all whitelist capable profiles are already. The only way we could make them all whitelist-only is if we add many more controls for users to specify their paths for different things.

Overall as it is now is probably close to perfect. Furthering with path restrictions in $HOME will increase the difficulty and cause users to stop using it.

@SkewedZeppelin commented on GitHub (Jul 28, 2018): We discussed this a while ago, nearly all whitelist capable profiles are already. The only way we could make them all whitelist-only is if we add many more controls for users to specify their paths for different things. Overall as it is now is probably close to perfect. Furthering with path restrictions in $HOME will increase the difficulty and cause users to stop using it.

gitea-mirror commented

2026-05-05 08:03:34 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

😞 Fair enough.

@chiraag-nataraj commented on GitHub (Jul 28, 2018): :disappointed: Fair enough.

gitea-mirror commented

2026-05-05 08:03:35 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

I guess I don't see restricting browsers and most other programs to ${DOWNLOADS} and their own folders (and possibly ${DOCUMENTS} or something else depending on the program) as being that hard to deal with. Maybe it's just a personal thing, but I actually find it more intuitive that programs can't access whatever directories they want and are restricted to a specific set of well-known directories.

@chiraag-nataraj commented on GitHub (Jul 28, 2018): I guess I don't see restricting browsers and most other programs to `${DOWNLOADS}` and their own folders (and possibly `${DOCUMENTS}` or something else depending on the program) as being that hard to deal with. Maybe it's just a personal thing, but I actually find it more intuitive that programs can't access whatever directories they want and are restricted to a specific set of well-known directories.

gitea-mirror commented

2026-05-05 08:03:36 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

Actually, I will re-open. What additional controls do you think we need?

@chiraag-nataraj commented on GitHub (Jul 28, 2018): Actually, I will re-open. What additional controls do you think we need?

gitea-mirror commented

2026-05-05 08:03:37 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 28, 2018):

Well I really like the whole disable-xdg.inc thing, but it is limited to Documents, Pictures, Music, and Videos.
We have Downloads and Desktop which I consider to be catch-all directories.

We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive?

I don't know what controls we would need. There are so many ways. Like whitelist options that only enable if a config option is enabled.

Or our own xdg like config to allow users to define categories to their folders. Like a setup wizard that would let a user mark what all of their directories are and then each profile would define what categories they need access to.

But how would you make a whitelist only image viewer even with categories?
What about when someone has their backup drive connected? etc.

.

I still want a whitelist-noblacklisted option, it would make it easier to convert blacklist to whitelist profiles and to maintain them. See 0f1e88789d and #1569

@SkewedZeppelin commented on GitHub (Jul 28, 2018): Well I really like the whole disable-xdg.inc thing, but it is limited to Documents, Pictures, Music, and Videos. We have Downloads and Desktop which I consider to be catch-all directories. We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive? I don't know what controls we would need. There are so many ways. Like whitelist options that only enable if a config option is enabled. Or our own xdg like config to allow users to define categories to their folders. Like a setup wizard that would let a user mark what all of their directories are and then each profile would define what categories they need access to. But how would you make a whitelist only image viewer even with categories? What about when someone has their backup drive connected? etc. . I still want a `whitelist-noblacklisted` option, it would make it easier to convert blacklist to whitelist profiles and to maintain them. See https://github.com/SkewedZeppelin/firejail/commit/0f1e88789daea4613d677f0326c9c36c68f279c6 and #1569

gitea-mirror commented

2026-05-05 08:03:37 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive?

That can be handled by local modifications for people who need it. They can whitelist additional directories in .local files. I mean, the fact that not everyone uses these directories doesn't negate the fact that most people do use these directories, and using the canonical directories as a reasonable whitelist makes sense. Given that you can always extend that with e.g. ignore disable-mnt and whitelist <additional directory>, I don't see what the problem is with having a reasonably restricted whitelist by default.

@chiraag-nataraj commented on GitHub (Jul 28, 2018): > We could further lock down many of the IDE profiles if we had a Development variable. But then how do you handle people with their code or in other directories? Datasets on another drive? That can be handled by local modifications for people who need it. They can whitelist additional directories in `.local` files. I mean, the fact that not _everyone_ uses these directories doesn't negate the fact that _most_ people do use these directories, and using the canonical directories as a reasonable whitelist makes sense. Given that you can always extend that with e.g. `ignore disable-mnt` and `whitelist <additional directory>`, I don't see what the problem is with having a reasonably restricted whitelist by default.

gitea-mirror commented

2026-05-05 08:03:38 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

IDEs specifically are a bit tricky in that their canonical directories aren't necessarily fixed (e.g. Eclipse lets you set the workspace location). But again, we can set sensible defaults and .local modifications will take care of the rest.

@chiraag-nataraj commented on GitHub (Jul 28, 2018): IDEs specifically are a bit tricky in that their canonical directories aren't necessarily fixed (e.g. Eclipse lets you set the workspace location). But again, we can set sensible defaults and `.local` modifications will take care of the rest.

gitea-mirror commented

2026-05-05 08:03:39 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

Already, many of our profiles will require some local modifications. For example, some people had their /tmp mounted in /mnt or something. That doesn't mean we shouldn't enable disable-mnt by default, right?

@chiraag-nataraj commented on GitHub (Jul 28, 2018): Already, many of our profiles will require some local modifications. For example, some people had their `/tmp` mounted in `/mnt` or something. That doesn't mean we shouldn't enable `disable-mnt` by default, right?

gitea-mirror commented

2026-05-05 08:03:40 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 28, 2018):

I think we should try to minimize the need of .local profiles as much as possible, unless the benefit dramatically outweighs the hassle of it (like disable-mnt does).
(As it stands now a user can just apt install then firecfg, which is dead simple and should be maintained)

Unless we create an easy way to allow users to define what directories are what, I don't think we'll be able to much further restrict directories in $HOME.

@SkewedZeppelin commented on GitHub (Jul 28, 2018): I think we should try to minimize the need of .local profiles as much as possible, unless the benefit dramatically outweighs the hassle of it (like disable-mnt does). (As it stands now a user can just `apt install` then `firecfg`, which is dead simple and should be maintained) Unless we create an easy way to allow users to define what directories are what, I don't think we'll be able to much further restrict directories in $HOME.

gitea-mirror commented

2026-05-05 08:03:40 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 28, 2018):

In the short term, if we want to convert some blacklist profiles to whitelist-only without breakage:

Add a new profile option called if-strictmode
- This would prefix all restrictive options that are common but might break more complicated setups
- So: if-strictmode whitelist ${DOCUMENTS} could be added to LibreOffice
Add a new option strictmode to firejail.config
- This would enable all options masked by the if-strictmode
Add a prompt when firecfg is run that asks if they want to enable strictmode

@SkewedZeppelin commented on GitHub (Jul 28, 2018): In the short term, if we want to convert some blacklist profiles to whitelist-only without breakage: - Add a new profile option called `if-strictmode` * This would prefix all restrictive options that are common but might break more complicated setups * So: `if-strictmode whitelist ${DOCUMENTS}` could be added to LibreOffice - Add a new option `strictmode` to firejail.config * This would enable all options masked by the `if-strictmode` - Add a prompt when `firecfg` is run that asks if they want to enable `strictmode`

gitea-mirror commented

2026-05-05 08:03:41 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

I guess I'll continue doing those on my own then 😂 I understand where you're coming from - I guess I just completely disagree with the premise. I think it's reasonable to expect that most people will use the canonical folders (i.e. the defaults) for the programs they use, and I don't see any harm in restricting the program to those folders by default.

@chiraag-nataraj commented on GitHub (Jul 28, 2018): I guess I'll continue doing those on my own then :joy: I understand where you're coming from - I guess I just completely disagree with the premise. I think it's reasonable to expect that most people will use the canonical folders (i.e. the defaults) for the programs they use, and I don't see any harm in restricting the program to those folders by default.

gitea-mirror commented

2026-05-05 08:03:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 28, 2018):

Huh, that would be interesting. We should think about implementing that :)

@chiraag-nataraj commented on GitHub (Jul 28, 2018): Huh, that would be interesting. We should think about implementing that :)

gitea-mirror commented

2026-05-05 08:03:43 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 28, 2018):

The issue is that a lot of programs don't have defaults.
GIMP stores in ~/Documents by default, but a user might want it to be in ~/Pictures.
And then a freelancer/artist might want to have a ~/Work folder.
Or when they archive stuff to an external drive.

I want strict profiles, but I also want to maintain the ease of use and not cause users to turn away/uninstall when they realize they have to edit a bunch of config files.

@SkewedZeppelin commented on GitHub (Jul 28, 2018): The issue is that a lot of programs don't have defaults. GIMP stores in ~/Documents by default, but a user might want it to be in ~/Pictures. And then a freelancer/artist might want to have a ~/Work folder. Or when they archive stuff to an external drive. I want strict profiles, but I also want to maintain the ease of use and not cause users to turn away/uninstall when they realize they have to edit a bunch of config files.

gitea-mirror commented

2026-05-05 08:03:43 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jul 29, 2018):

IMO it would be great to have option for blacklisting all dotfiles in user $HOME (unless there is noblacklist or whitelist option used for specific files). I don't think users are creating custom dotfiles (if they do, they are probably more advanced and can handle it in .local) and with recent XDG black/whitelisting it will be easy to create quite strict sandbox, example:

whitelist ~/.config/app
whitelist ~/local/share/app
include whitelist-common.inc
blacklist .dotfiles
blacklist $XDG_VIDEOS

@Vincent43 commented on GitHub (Jul 29, 2018): IMO it would be great to have option for blacklisting all dotfiles in user $HOME (unless there is noblacklist or whitelist option used for specific files). I don't think users are creating custom dotfiles (if they do, they are probably more advanced and can handle it in .local) and with recent XDG black/whitelisting it will be easy to create quite strict sandbox, example: ``` whitelist ~/.config/app whitelist ~/local/share/app include whitelist-common.inc blacklist .dotfiles blacklist $XDG_VIDEOS ```

gitea-mirror commented

2026-05-05 08:03:44 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Jul 29, 2018):

@chiraag-nataraj : I think it's a great idea. However, I think before implementing this it would be necessary to improve file globbing. For example, a rule like

whitelist ${HOME}/*.pdf

does not work. This makes creating whitelisted profiles for applications like Okular and Gwenview difficult or, at least, not very efficient.

Sidenote: It's really great that you've attended to many "forgotten" issues here in the past days. Many thanks for your efforts!!!

@curiosity-seeker commented on GitHub (Jul 29, 2018): @chiraag-nataraj : I think it's a great idea. However, I think before implementing this it would be necessary to improve file globbing. For example, a rule like `whitelist ${HOME}/*.pdf` does not work. This makes creating whitelisted profiles for applications like Okular and Gwenview difficult or, at least, not very efficient. Sidenote: It's really great that you've attended to many "forgotten" issues here in the past days. Many thanks for your efforts!!!

gitea-mirror commented

2026-05-05 08:03:44 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

@curiosity-seeker: Yeah, we definitely need to implement #216.

And thanks hehe :)

@chiraag-nataraj commented on GitHub (Jul 29, 2018): @curiosity-seeker: Yeah, we definitely need to implement #216. And thanks hehe :)

gitea-mirror commented

2026-05-05 08:03:45 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

Although...at that point, would it be better to use apparmor to allow access e.g. only to PDF files? I don't know...

@chiraag-nataraj commented on GitHub (Jul 29, 2018): Although...at that point, would it be better to use apparmor to allow access e.g. _only_ to PDF files? I don't know...

gitea-mirror commented

2026-05-05 08:03:45 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jul 29, 2018):

AppArmor rules affect all profiles

@Vincent43 commented on GitHub (Jul 29, 2018): AppArmor rules affect all profiles

gitea-mirror commented

2026-05-05 08:03:45 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 29, 2018):

Oh right, nvm.

@chiraag-nataraj commented on GitHub (Jul 29, 2018): Oh right, nvm.

Rows
Columns

[GH-ISSUE #2070] [Proposal] Convert all profiles to a whitelist model #1398