prevent info leakage through /proc

[brussell1]

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?

[SkewedZeppelin]

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.

[Vincent43]

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

[chiraag-nataraj]

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

[Vincent43]

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

[chiraag-nataraj]

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).

[Vincent43]

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

[chiraag-nataraj]

Yeah, and sometimes that includes firejailed processes.

[chiraag-nataraj]

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

[Vincent43]

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

[brussell1]

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

[Vincent43]

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

[Vincent43]

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

[brussell1]

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

[chiraag-nataraj]

@netblue30 Any comments on this?

[chiraag-nataraj]

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

[SkewedZeppelin]

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

[glitsj16]

@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).