[GH-ISSUE #959] Firefox blacklist violation for fontconfig

gitea-mirror commented

2026-05-05 06:21:43 -06:00

Owner

Originally created by @acrobat1 on GitHub (Dec 6, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/959

I have no idea if this is a relevant issue or am I doing something I'm not supposed to, however if I run Firefox with the --private=directory option in Firejail 0.9.44 with a profile and/or commandline option to blacklist /home/user/.cache/fontconfig, after a while I can see this message in the logs

blacklist violation - sandbox 10331, exe firefox, syscall access, path /home/user/.cache/fontconfig

blacklist violation - sandbox 10331, exe firefox, syscall access, path /home/user/.fontconfig

so not only Firefox is using the .cache/fontconfig directory in the private directory, it is also creating a new .fontconfig directory at the upper level: is that an issue?

Does Firefox absolutely need to use the fonts cache?
As far as I can see, apparently this is only happening when using the --private=directory option (first I launch Firefox to let firejail create the new firefox profile inside that private directory, than overwrite its contents with files from a custom profile), otherwise I can't see that message in the logs - so why would Firefox need to access the fonts config only with --private=directory option, violating the blacklisting, and apparently respect the fontconfig blacklisting in "normal" sandboxed mode ?

Isn't the font cache a vector for some kind of fingerprinting/tracking activity?

Originally created by @acrobat1 on GitHub (Dec 6, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/959 I have no idea if this is a relevant issue or am I doing something I'm not supposed to, however if I run Firefox with the **--private=directory option** in Firejail 0.9.44 with a profile and/or commandline option to blacklist /home/user/.cache/fontconfig, after a while I can see this message in the logs `blacklist violation - sandbox 10331, exe firefox, syscall access, path /home/user/.cache/fontconfig` `blacklist violation - sandbox 10331, exe firefox, syscall access, path /home/user/.fontconfig` so not only Firefox is using the .cache/fontconfig directory in the private directory, it is also creating a new .fontconfig directory at the upper level: is that an issue? Does Firefox absolutely need to use the fonts cache? As far as I can see, apparently this is only happening when using the **--private=directory** option (first I launch Firefox to let firejail create the new firefox profile inside that private directory, than overwrite its contents with files from a custom profile), otherwise I can't see that message in the logs - so why would Firefox need to access the fonts config only with --private=directory option, violating the blacklisting, and apparently respect the fontconfig blacklisting in "normal" sandboxed mode ? Isn't the font cache a vector for some kind of fingerprinting/tracking activity?

gitea-mirror

2026-05-05 06:21:43 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:21:49 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 8, 2016):

Yes, most programs end up using fontconfig directories - I guess is one of Xorg libraries doing it.n There seem to be 3 directories, depending on Xorg version: ~/.fontconfig, ~/.config/fontconfig, ~/.cache/fontconfig

@netblue30 commented on GitHub (Dec 8, 2016): Yes, most programs end up using fontconfig directories - I guess is one of Xorg libraries doing it.n There seem to be 3 directories, depending on Xorg version: ~/.fontconfig, ~/.config/fontconfig, ~/.cache/fontconfig

gitea-mirror commented

2026-05-05 06:21:52 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 18, 2016):

@acrobat1 If, indeed, it's a vector for tracking and fingerprinting (and that seems likely), the way to defeat it is most likely by disabling Javascript unless it's needed on a site (e.g. NoScript or uMatrix in block-by-default mode will do the trick).

@chiraag-nataraj commented on GitHub (Dec 18, 2016): @acrobat1 If, indeed, it's a vector for tracking and fingerprinting (and that seems likely), the way to defeat it is most likely by disabling Javascript unless it's needed on a site (e.g. NoScript or uMatrix in block-by-default mode will do the trick).

gitea-mirror commented

2026-05-05 06:21:57 -06:00

Author

Owner

@acrobat1 commented on GitHub (Dec 21, 2016):

I surely agree on selectively enabling JS and disabling remote fonts with either NoScript/uBlock/uMatrix.

Still, why isn't Firejail able to enforce the fontconfig blacklisting only when using the --private=directory argument ?

so why would Firefox need to access the fonts config only with --private=directory option, violating the blacklisting, and apparently respect the fontconfig blacklisting in "normal" sandboxed mode ?

@acrobat1 commented on GitHub (Dec 21, 2016): I surely agree on selectively enabling JS and disabling remote fonts with either NoScript/uBlock/uMatrix. Still, why isn't Firejail able to enforce the fontconfig blacklisting only when using the --private=directory argument ? >so why would Firefox need to access the fonts config only with --private=directory option, violating the blacklisting, and apparently respect the fontconfig blacklisting in "normal" sandboxed mode ?

gitea-mirror commented

2026-05-05 06:22:00 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 15, 2017):

I don't know if I correctly understand this, so correct me if I'm wrong. From what you're saying, it seems that Firefox doesn't try to access ~/.fontconfig if you don't use --private. Furthermore, it tries to access the folder if you use --private and thus triggers a syslog message. This might imply that Firefox has some local cache it uses in the profile and only tries to access ~/.fontconfig if that local cache (in the profile folder) doesn't exist.

@chiraag-nataraj commented on GitHub (Jan 15, 2017): I don't know if I correctly understand this, so correct me if I'm wrong. From what you're saying, it seems that Firefox doesn't try to access `~/.fontconfig` if you don't use `--private`. Furthermore, it tries to access the folder if you use `--private` and thus triggers a syslog message. This might imply that Firefox has some local cache it uses in the profile and only tries to access `~/.fontconfig` if that local cache (in the profile folder) doesn't exist.

gitea-mirror commented

2026-05-05 06:22:03 -06:00

Author

Owner

@acrobat1 commented on GitHub (Jan 27, 2017):

Thanks for your reply, I'll have to delve into this a bit more and report back later on.

@acrobat1 commented on GitHub (Jan 27, 2017): Thanks for your reply, I'll have to delve into this a bit more and report back later on.

gitea-mirror commented

2026-05-05 06:22:07 -06:00

Author

Owner

@acrobat1 commented on GitHub (Feb 5, 2017):

From what you're saying, it seems that Firefox doesn't try to access ~/.fontconfig if you don't use --private

That seems to be the case: as far as I can see, if I don't use --private, no warnings appear in the logs.

If on the other hand I do use --private, at some point it will create (or even re-create if it has been manually deleted) the ~/.fontconfig directory inside the private home directory in use.

@acrobat1 commented on GitHub (Feb 5, 2017): >From what you're saying, it seems that Firefox doesn't try to access ~/.fontconfig if you don't use --private That seems to be the case: as far as I can see, if I don't use --private, no warnings appear in the logs. If on the other hand I do use --private, at some point it will create (or even re-create if it has been manually deleted) the ~/.fontconfig directory inside the private home directory in use.

gitea-mirror commented

2026-05-05 06:22:09 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 5, 2017):

So...that's interesting. I took a look and mine does the same thing. Specifically, my firefox creates a ~/.cache/fontconfig directory inside the jail. I don't think you have to worry about that - it's going to do it and there isn't much you can do about it per se. What would be worrying is if it were somehow circumventing the jail and accessing the real ~/.fontconfig (or ~/.cache/fontconfig or whatever) directory, which I don't think is happening.

That being said, I'm not sure where it's storing the information. Just as a confirmation:
firejail --blacklist=~/.cache/fontconfig firefox doesn't raise an error, but firejail --private --blacklist=~/.cache/fontconfig firefox does, right? I'm just asking because you never specified the exact commands. For best results when testing, it's also probably good to use --noprofile as well, so
firejail --noprofile --blacklist=~/.cache/fontconfig firefox
firejail --noprofile --private --blacklist=~/.cache/fontconfig firefox

@chiraag-nataraj commented on GitHub (Feb 5, 2017): So...that's interesting. I took a look and mine does the same thing. Specifically, my firefox creates a `~/.cache/fontconfig` directory inside the jail. I don't think you have to worry about that - it's going to do it and there isn't much you can do about it per se. What _would_ be worrying is if it were somehow circumventing the jail and accessing the real `~/.fontconfig` (or `~/.cache/fontconfig` or whatever) directory, which I don't think is happening. That being said, I'm not sure where it's storing the information. Just as a confirmation: `firejail --blacklist=~/.cache/fontconfig firefox` doesn't raise an error, but `firejail --private --blacklist=~/.cache/fontconfig firefox` does, right? I'm just asking because you never specified the exact commands. For best results when testing, it's also probably good to use `--noprofile` as well, so `firejail --noprofile --blacklist=~/.cache/fontconfig firefox` `firejail --noprofile --private --blacklist=~/.cache/fontconfig firefox`

gitea-mirror referenced this issue

2026-05-05 10:06:17 -06:00

[PR #654] [MERGED] Add profile for uudeview #3700

Rows
Columns

[GH-ISSUE #959] Firefox blacklist violation for fontconfig #654