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

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.

added component::archived/tor browser sandbox owner::yawning priority::medium resolution::wontfix sandbox-security severity::normal status::closed type::enhancement labels

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

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

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

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

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.

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.

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.

Trac:
Keywords: N/A deleted, sandbox-security added

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.

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

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

Trac:
Status: new to closed
Resolution: N/A to wontfix

closed

mentioned in issue #22853 (closed)