Opened 3 years ago

Closed 15 months ago

#20773 closed enhancement (wontfix)

Stop mounting `/proc` in the various containers once this is feasable.

Reported by: yawning Owned by: yawning
Priority: Medium Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords: sandbox-security
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

All three containers currently used by sandboxed-tor-browser (tor, firefox, and the updater) currently mount /proc. Once it's been verified that relevant versions of the software shipped do not require such, this mount should be removed to reduce fingerprinting and to close an attack vector.

In the mean time, stopgap solutions such as AppArmor could be investigated as well, though that is not a good long term solution as it is not ubiquitous.

Child Tickets

TicketTypeStatusOwnerSummary
#20283defectclosedpospeselrTor Browser should run without a `/proc` filesystem.

Change History (11)

comment:1 Changed 3 years ago by yawning

As far as I can tell, the tor process container can do without /proc. It's clear cut for the no PT case since tor appears to only use /proc/meminfo to derive MaxMemInQueues which is irrelevant for this use case.

obfs4proxy appears to read from /proc as well upon cursory examination via strings, but it doesn't appear to crash and I can browse the web in a container sans procfs. However before I disable mounting it in the container, I'd like to see what exactly it's doing.

I need to strace tor + obfs4proxy anyway when I decide to tackle #20782...

comment:2 Changed 3 years ago by yawning

In the mean time while I fret over obfs4proxy behavior that will probably end up being harmless, I went ahead and disabled mounting /proc in the tor container when Bridges aren't in use. Half a container down, 2.5 containers to go.

https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/commit/?id=f5dbc78776f413829085aa3fba2611214cc469ad

comment:3 Changed 3 years ago by yawning

Looking at the go runtime library's use of "/proc" as of 1.7.3:

  • src/syscall/exec_linux.go - /proc/$PID/[setgroups,uid_map,gid_map]
  • src/runtime/pprof/pprof.go - /proc/self/maps
  • src/os/sys_linux.go - /proc/sys/kernel/hostname
  • src/net/sock_linux.go - /proc/sys/net/core/somaxconn
  • src/net/interface_linux.go - /proc/net/[igmp,igmp6]
  • src/cmd/internal/pprof/report/source.go - /proc/self/cwd
  • src/cmd/dist/build.go - /proc/$PID/ns

The files that may be accessed by obfs4proxy are:

  • /proc/sys/kernel/hostname which is compiled in because the log package has syslog support.
  • /proc/sys/net/core/somaxconn which is used to determine the listen() backlog, but will default to 128 if the read/parse fails in any way.

Based on this I shall disable /proc entirely for the tor container.

https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/commit/?id=db09c0bb793c705a13e275dc6d52eed70ca95c80

comment:4 Changed 3 years ago by yawning

Asan requires /proc/self/maps at a minimum, so for the hardened series, the tor container yet again has /proc/. Sad panda.

https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/commit/?id=09b66528f6013c0ca5ee9be20ad91cadb3e901aa

comment:5 Changed 3 years ago by yawning

Related, sysinfo() probably should be killed by seccomp, and enough of it stubbed out to make firefox happy, since the information is also not great for firefox to have.

comment:6 Changed 3 years ago by yawning

One thing that I *could* do, but would rather not is to do something like lxcfs and have the container "/proc" be serviced by a FUSE process in the host system.

This would work, but I'm inclined to reject this due to:

  • Yet another dependency, that needs to be SUID root.
  • It would be a lot of code.
  • Patching firefox to not fall over seems easier than "not-invented-here-ing" a filesystem.

comment:7 in reply to:  6 Changed 3 years ago by cypherpunks

Replying to yawning:

One thing that I *could* do, but would rather not is to do something like lxcfs and have the container "/proc" be serviced by a FUSE process in the host system.

This would work, but I'm inclined to reject this due to:

  • Yet another dependency, that needs to be SUID root.
  • It would be a lot of code.
  • Patching firefox to not fall over seems easier than "not-invented-here-ing" a filesystem.

Please don't do this. FUSE is a mess, and SUID root just makes it almost worse than downright allowing access to /proc. Just don't mount it.

comment:8 Changed 3 years ago by yawning

Keywords: sandbox-security added

comment:9 Changed 2 years ago by yawning

https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/commit/?id=95857360ec7f84cf9f0a01855c15881c89919133

The only place that has /proc mounted is the updater container, which while also important is not nearly as scary as firefox having access to /proc, as the updater ostensibly only is fed signed/trusted inputs, and doesn't have any sort of network access at all.

Firefox is still moderately unhappy about the lack of /proc and will warn:

2017/07/03 17:26:21 firefox: Sandbox: unexpected multithreading found; this prevents using namespace sandboxing.  (If you're LD_PRELOAD'ing nVidia GL: that's not necessary for Gecko.)

But nested namespaces are asking for a world of hurt, so it's unlikely that it worked prior to this to begin with.

comment:10 Changed 2 years ago by yawning

#23915 is more fallout from this, that needs to be accounted for in the future.

comment:11 Changed 15 months ago by yawning

Resolution: wontfix
Status: newclosed

This project is deprecated, and none of these will ever be fixed.

Note: See TracTickets for help on using tickets.