[GH-ISSUE #1926] prevent info leakage through /proc

gitea-mirror commented

2026-05-05 07:48:07 -06:00

Owner

Originally created by @brussell1 on GitHub (May 5, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1926

Blacklisting /proc works, though breaks some programs (firefox).
It's also possible to blacklist various information like "blacklist /proc/cpuinfo".
Unfortunately I'm not able to deny access to /proc/mounts or /proc/self/*.
E.g. right now all mountpoints of the host are visible, including all firejail related, which, imo, shouldn't be accessible in a sandbox.
Is there a solution to this problem?

Originally created by @brussell1 on GitHub (May 5, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1926 Blacklisting /proc works, though breaks some programs (firefox). It's also possible to blacklist various information like "blacklist /proc/cpuinfo". Unfortunately I'm not able to deny access to /proc/mounts or /proc/self/*. E.g. right now all mountpoints of the host are visible, including all firejail related, which, imo, shouldn't be accessible in a sandbox. Is there a solution to this problem?

gitea-mirror added the

question_old

label 2026-05-05 07:48:07 -06:00

gitea-mirror commented

2026-05-05 07:48:11 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (May 5, 2018):

There are already a few restrictions on /proc via Firejail itself. If you want system wide ones you can use hidepid, but that comes with some issues too.

Grsecurity has features to further restrict /proc via GRKERNSEC_PROC_ADD and even restrictions of /sysfs. As powerful as they are, they caused a ton of breakage on the desktop side and (I assume) were more intended for use on the single application server side.

I'm sure the situation can be improved, but there is a lot to it.

@SkewedZeppelin commented on GitHub (May 5, 2018): There are already a few restrictions on /proc via Firejail itself. If you want system wide ones you can use hidepid, but that comes with some issues too. Grsecurity has features to further restrict [/proc](https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Proc_restrictions) via `GRKERNSEC_PROC_ADD` and even restrictions of [/sysfs](https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sysfs/debugfs_restriction). As powerful as they are, they caused a ton of breakage on the desktop side and (I assume) were more intended for use on the single application server side. I'm sure the situation can be improved, but there is a lot to it.

gitea-mirror commented

2026-05-05 07:48:13 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 5, 2018):

Grsecurity public patches are no more anyway. hidepid is the way to go.

@Vincent43 commented on GitHub (May 5, 2018): Grsecurity public patches are no more anyway. `hidepid` is the way to go.

gitea-mirror commented

2026-05-05 07:48:15 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 5, 2018):

Just a side note, I've had issues with hidepid=2 and systemd/logind not cleaning up sessions. One way to fix this (if you care - I don't think it actually impacts anything besides having tons of zombie sessions in loginctl list-sessions) is creating a special group (I called it proc), mounting proc with hidepid=2,gid=<gid> with <gid> being the gid from the group created in the previous step, and adding your user and polkitd to that group. At least...I think it's solved that issue...I don't generally log out once I've logged in, so it's hard to know if that was the issue 😂
/endrant

@chiraag-nataraj commented on GitHub (May 5, 2018): Just a side note, I've had issues with `hidepid=2` and `systemd`/`logind` not cleaning up sessions. One way to fix this (if you care - I don't think it actually impacts anything besides having tons of zombie sessions in `loginctl list-sessions`) is creating a special group (I called it proc), mounting proc with `hidepid=2,gid=<gid>` with `<gid>` being the gid from the group created in the previous step, and adding your user and `polkitd` to that group. At least...I _think_ it's solved that issue...I don't generally log out once I've logged in, so it's hard to know if that was the issue :joy: /endrant

gitea-mirror commented

2026-05-05 07:48:16 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 5, 2018):

Adding yourself to hidepid gid will defeat the purpose of using it with firejail (it still will affect system-wide daemons running as non-root but that is unrelated to this case). I think adding logind and polkit should be enough:

/etc/systemd/system/systemd-logind.service.d/hidepid.conf

[Service]
SupplementaryGroups=proc

@Vincent43 commented on GitHub (May 5, 2018): Adding yourself to hidepid gid will defeat the purpose of using it with firejail (it still will affect system-wide daemons running as non-root but that is unrelated to this case). I think adding logind and polkit should be enough: ``` /etc/systemd/system/systemd-logind.service.d/hidepid.conf [Service] SupplementaryGroups=proc ```

gitea-mirror commented

2026-05-05 07:48:18 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 5, 2018):

Oh right, you have to add logind to the group as well. For some reason, I think I had issues until I added my user as well. I'm also thinking about removing my user from the group anyway since I don't log out often (so the zombie sessions don't really have an impact on me).

@chiraag-nataraj commented on GitHub (May 5, 2018): Oh right, you have to add `logind` to the group as well. For some reason, I think I had issues until I added my user as well. I'm also thinking about removing my user from the group anyway since I don't log out often (so the zombie sessions don't really have an impact on me).

gitea-mirror commented

2026-05-05 07:48:19 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 5, 2018):

Keep in mind that by removing your user from hidepid whitelist you loose ability to monitor system-wide processes from user account.

@Vincent43 commented on GitHub (May 5, 2018): Keep in mind that by removing your user from hidepid whitelist you loose ability to monitor system-wide processes from user account.

gitea-mirror commented

2026-05-05 07:48:20 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 5, 2018):

Yeah, and sometimes that includes firejailed processes.

@chiraag-nataraj commented on GitHub (May 5, 2018): Yeah, and sometimes that includes firejailed processes.

gitea-mirror commented

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

Author

Owner

@chiraag-nataraj commented on GitHub (May 5, 2018):

By the way, hidepid=2 won't blacklist /proc/mounts or /proc/self, so while it's useful, it won't solve the OP.

@chiraag-nataraj commented on GitHub (May 5, 2018): By the way, `hidepid=2` won't blacklist `/proc/mounts` or `/proc/self`, so while it's useful, it won't solve the OP.

gitea-mirror commented

2026-05-05 07:48:23 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 5, 2018):

I see below in logs:

$ firejail --debug --noprofile --blacklist=/proc/mounts bash
...
Disable /proc/1/mounts (requested /proc/mounts)
...

$ cat /proc/1/mounts
cat: /proc/1/mounts: Permission denied

@Vincent43 commented on GitHub (May 5, 2018): I see below in logs: ``` $ firejail --debug --noprofile --blacklist=/proc/mounts bash ... Disable /proc/1/mounts (requested /proc/mounts) ... $ cat /proc/1/mounts cat: /proc/1/mounts: Permission denied ```

gitea-mirror commented

2026-05-05 07:48:23 -06:00

Author

Owner

@brussell1 commented on GitHub (May 5, 2018):

@Vincent43
And whats with "cat /proc/mounts". Try it out...

@brussell1 commented on GitHub (May 5, 2018): @Vincent43 And whats with "cat /proc/mounts". Try it out...

gitea-mirror commented

2026-05-05 07:48:25 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 5, 2018):

I know. I just demonstrated what is happening. I don't know if it's a bug or feature.

@Vincent43 commented on GitHub (May 5, 2018): I know. I just demonstrated what is happening. I don't know if it's a bug or feature.

gitea-mirror commented

2026-05-05 07:48:27 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 6, 2018):

You can block various /proc and /sys entries through AppArmor integration, example:

# /etc/apparmor.d/local/firejail-local
deny /proc/mounts r,
deny /proc/mountinfo r,

deny /proc/@{PID}/mounts r,
deny /proc/@{PID}/mountinfo r,

$ firejail --apparmor --noprofile bash

$ findmnt
findmnt: can't read /proc/self/mountinfo: Permission denied

$ cat /proc/mounts
cat: /proc/mounts: Permission denied

@Vincent43 commented on GitHub (May 6, 2018): You can block various /proc and /sys entries through AppArmor integration, example: ``` # /etc/apparmor.d/local/firejail-local deny /proc/mounts r, deny /proc/mountinfo r, deny /proc/@{PID}/mounts r, deny /proc/@{PID}/mountinfo r, ``` ``` $ firejail --apparmor --noprofile bash $ findmnt findmnt: can't read /proc/self/mountinfo: Permission denied $ cat /proc/mounts cat: /proc/mounts: Permission denied ```

gitea-mirror commented

2026-05-05 07:48:28 -06:00

Author

Owner

@brussell1 commented on GitHub (May 7, 2018):

Thanks for the info Vincent43. Though I would like to hear the opinion of netblue30 regarding this matter.

@brussell1 commented on GitHub (May 7, 2018): Thanks for the info Vincent43. Though I would like to hear the opinion of netblue30 regarding this matter.

gitea-mirror commented

2026-05-05 07:48:29 -06:00

Author

Owner

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

@netblue30 Any comments on this?

@chiraag-nataraj commented on GitHub (Jul 30, 2018): @netblue30 Any comments on this?

gitea-mirror commented

2026-05-05 07:48:31 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 21, 2019):

@netblue30, is this something we want to work on within firejail or is this outside the scope of the project?

@chiraag-nataraj commented on GitHub (May 21, 2019): @netblue30, is this something we want to work on within firejail or is this outside the scope of the project?

gitea-mirror commented

2026-05-05 07:48:32 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jul 21, 2022):

A comment I've read regarding Tor browser profiles:

yeah but people should block/deny access to /sys/net/class in firejail or apparmor as that is location of real MAC Address and has been used in past to deanonimize before

Files like /sys/class/net/wlp1s0/address do indeed contain the MAC address

@SkewedZeppelin commented on GitHub (Jul 21, 2022): A comment I've read regarding Tor browser profiles: > yeah but people should block/deny access to `/sys/net/class` in firejail or apparmor as that is location of real MAC Address and has been used in past to deanonimize before Files like /sys/class/net/wlp1s0/address do indeed contain the MAC address

gitea-mirror commented

2026-05-05 07:48:33 -06:00

Author

Owner

@ghost commented on GitHub (Jul 23, 2022):

@SkewedZeppelin IMO we should add a blacklist /sys/class/net to the relevant Tor profiles to mitigate deanonimazation attempts. Great catch! Are you planning on opening a PR for this?

Off-topic: unfortunately the --mac=address option is not supported for wireless interfaces. But there are several other options available on most distro's for MAC address spoofing (fully or partially).

@ghost commented on GitHub (Jul 23, 2022): @SkewedZeppelin IMO we should add a `blacklist /sys/class/net` to the relevant Tor profiles to mitigate deanonimazation attempts. Great catch! Are you planning on opening a PR for this? Off-topic: unfortunately the `--mac=address` option is not supported for wireless interfaces. But there are several other options available on most distro's for [MAC address spoofing](https://wiki.archlinux.org/title/MAC_address_spoofing) (fully or partially).

Rows
Columns

[GH-ISSUE #1926] prevent info leakage through /proc #1289