[GH-ISSUE #7117] Add a way to fake files in /proc #3492

Open
opened 2026-05-05 10:01:49 -06:00 by gitea-mirror · 2 comments
Owner

Originally created by @stanson-ch on GitHub (Mar 29, 2026).
Original GitHub issue: https://github.com/netblue30/firejail/issues/7117

Firefox always trying to eventually eat all memory available. rlimit-as option does not work as expected at all, since, as I understand it limit only single process, not an application as whole, that could spawn hundreds of processes.

But it looks like if you bind a static file where MemTotal set to desired limit with other fields set like memory is nearly exhausted over /proc/meminfo, then Firefox sits within this limit and don't try to eat all memory.

Unfortunately, as I find in previous closed issues here, there is no any plans to allow bind option for firejail started under user, and it is a very bad idea to run Firefox as root even in firejail.

Overall, I want to be able to trick any program running under firejail about any system hardware parameters, say, through special option for faking at least /proc files. Faking /sys could be very useful too. Something like

proc-fake ${HOME}/.firefox-meminfo /proc/meminfo

where .firefox-meminfo is something like

MemTotal:        4194304 kB
MemFree:          350000 kB
MemAvailable:     512000 kB
Buffers:           50000 kB
Cached:           600000 kB
SwapCached:            0 kB
Active:          2500000 kB
Inactive:         800000 kB
Active(anon):    2000000 kB
Inactive(anon):     4000 kB
Active(file):     500000 kB
Inactive(file):   800000 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              1000 kB
Writeback:             0 kB
AnonPages:       2000000 kB
Mapped:           400000 kB
Shmem:            150000 kB
Slab:             300000 kB
CommitLimit:     4194304 kB
Committed_AS:    3194304 kB
DirectMap4k:      800000 kB
DirectMap2M:     3000000 kB

On a machine with, say, 32G RAM

I don't see any security issues in faking any hardware information for a program, and limiting browsers (and potentially other bloatware, say, Electron-based apps) memory appetites looks like a great solution in comparison with buying more and more RAM to satisfy some bloatware that demand more and more with every release.

Or, may be I missed something and there is already a way to fake /proc entry using existing options?

Originally created by @stanson-ch on GitHub (Mar 29, 2026). Original GitHub issue: https://github.com/netblue30/firejail/issues/7117 Firefox always trying to eventually eat all memory available. rlimit-as option does not work as expected at all, since, as I understand it limit only single process, not an application as whole, that could spawn hundreds of processes. But it looks like if you bind a static file where MemTotal set to desired limit with other fields set like memory is nearly exhausted over /proc/meminfo, then Firefox sits within this limit and don't try to eat all memory. Unfortunately, as I find in previous closed issues here, there is no any plans to allow bind option for firejail started under user, and it is a very bad idea to run Firefox as root even in firejail. Overall, I want to be able to trick any program running under firejail about any system hardware parameters, say, through special option for faking at least /proc files. Faking /sys could be very useful too. Something like ``` proc-fake ${HOME}/.firefox-meminfo /proc/meminfo ``` where .firefox-meminfo is something like ``` MemTotal: 4194304 kB MemFree: 350000 kB MemAvailable: 512000 kB Buffers: 50000 kB Cached: 600000 kB SwapCached: 0 kB Active: 2500000 kB Inactive: 800000 kB Active(anon): 2000000 kB Inactive(anon): 4000 kB Active(file): 500000 kB Inactive(file): 800000 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 1000 kB Writeback: 0 kB AnonPages: 2000000 kB Mapped: 400000 kB Shmem: 150000 kB Slab: 300000 kB CommitLimit: 4194304 kB Committed_AS: 3194304 kB DirectMap4k: 800000 kB DirectMap2M: 3000000 kB ``` On a machine with, say, 32G RAM I don't see any security issues in faking any hardware information for a program, and limiting browsers (and potentially other bloatware, say, Electron-based apps) memory appetites looks like a great solution in comparison with buying more and more RAM to satisfy some bloatware that demand more and more with every release. Or, may be I missed something and there is already a way to fake /proc entry using existing options?
gitea-mirror added the
enhancement
label 2026-05-05 10:01:49 -06:00
Author
Owner

@flingr commented on GitHub (Mar 29, 2026):

Have you tried https://github.com/netblue30/firejail/issues/2896#issuecomment-982643828 yet?

<!-- gh-comment-id:4149292460 --> @flingr commented on GitHub (Mar 29, 2026): Have you tried https://github.com/netblue30/firejail/issues/2896#issuecomment-982643828 yet?
Author
Owner

@stanson-ch commented on GitHub (Mar 29, 2026):

Have you tried #2896 (comment) yet?

  1. I don't use systemd
  2. Using cgroups, lxc, and vm manually you definitely can screw memory ambitions of browser, but then you also could do everything (and even more) firejail do, and then it is not clear why do you need firejail at all.
  3. memory limit is just an example why faking /proc and /sys entries could be useful.

Moreover, firejail now is a tool to mitigate undesired behaviour of a program in a modern circumstances when even opensource sofrware become a threat to a privacy and a source of BigData, not even talking about proprietary one. Firejail allow limit or deny access to various parts of filesystem and other environment. Why not take a step forward and make it a tool for creating any completely fake environment, not only allowing or not allowing access to data, but also faking any data to delude untrusted software in all ways possible.

I would also like to see firejail option to set fake system time or provide fake geolocation data to a sandboxed program along with faking files. It is a big step, I know, but I think there will be more and more demand for such features in near future, looking at the path modern software took.

With files it is relatively easy to implement using existing firejail code, all necessary part are already here, with other things more efforts will be needed, but I think it worth a try. I like firejail concept, and ease of use, so I would like to continue to use it, instead of switching to manually created containers with multiple additional tools like faketime and others. And something tell me that very soon, say browsers will just deny to start if they find that your XDG_PICTURES_DIR or XDG_DOCUMENTS_DIR is empty or inaccessible, because of IDK, "improving bult-in AI assistant feature user expirience", without a way to disable it, and even for opensource browsers you will need an enormous time and efforts to find and remove this "feature" from source code.

<!-- gh-comment-id:4150049696 --> @stanson-ch commented on GitHub (Mar 29, 2026): > Have you tried [#2896 (comment)](https://github.com/netblue30/firejail/issues/2896#issuecomment-982643828) yet? 1. I don't use systemd 2. Using cgroups, lxc, and vm manually you definitely can screw memory ambitions of browser, but then you also could do everything (and even more) firejail do, and then it is not clear why do you need firejail at all. 3. memory limit is just an example why faking /proc and /sys entries could be useful. Moreover, firejail now is a tool to mitigate undesired behaviour of a program in a modern circumstances when even opensource sofrware become a threat to a privacy and a source of BigData, not even talking about proprietary one. Firejail allow limit or deny access to various parts of filesystem and other environment. Why not take a step forward and make it a tool for creating any completely fake environment, not only allowing or not allowing access to data, but also faking any data to delude untrusted software in all ways possible. I would also like to see firejail option to set fake system time or provide fake geolocation data to a sandboxed program along with faking files. It is a big step, I know, but I think there will be more and more demand for such features in near future, looking at the path modern software took. With files it is relatively easy to implement using existing firejail code, all necessary part are already here, with other things more efforts will be needed, but I think it worth a try. I like firejail concept, and ease of use, so I would like to continue to use it, instead of switching to manually created containers with multiple additional tools like `faketime` and others. And something tell me that very soon, say browsers will just deny to start if they find that your XDG_PICTURES_DIR or XDG_DOCUMENTS_DIR is empty or inaccessible, because of IDK, "improving bult-in AI assistant feature user expirience", without a way to disable it, and even for opensource browsers you will need an enormous time and efforts to find and remove this "feature" from source code.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3492
No description provided.