[tbb-bugs] #20283 [Applications/Tor Browser]: Tor Browser should run without a `/proc` filesystem.
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Apr 12 00:08:49 UTC 2018
#20283: Tor Browser should run without a `/proc` filesystem.
-------------------------------------------------+-------------------------
Reporter: yawning | Owner:
| pospeselr
Type: defect | Status:
| needs_review
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-sandboxing, | Actual Points:
TorBrowserTeam201804R |
Parent ID: #20773 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by pospeselr):
Audited all the remaining syscalls (was only catch'ing open and openat
before) and discovered three more things which don't seem to be an issue
for us. Here's the full list of what we're working with (on x64 Linux)
roughly in order of invocation for future reference (open here covers both
open and openat, didn't save that data unfortunately):
||= Caller =||= syscall =||= Requested Path =||= Relevant Source ||
|| mozilla::HasUserNamespaceSupport() || access || "/proc/self/ns/user" ||
/security/sandbox/linux/SandboxInfo.cpp ||
|||||||| Failure here 'just' disables 'User Namespaces' (as shown under
the Sandbox section of about:support), not sure what the security
consequences of this is but tor browser boots and runs fine ||
|| selinuxfs_exists() || open ||"/proc/filessytems" || ||
|||||||| This call happens down in dlopen when opening libxul.so. Failure
to open this file will result in selinxufs_exists() always reporting
selinuxfs exists ( see
[https://github.com/SELinuxProject/selinux/blob/64afa1aff1cd610d2493f780e2a44b551f668b84/libselinux/src/init.c#L56
selinuxfs_exists(void)] but everything seems to go along even if it is a
false positive) ||
|| mozilla::(anonymous namespace)::IsSingleThreaded () || xstat ||
"/proc/self/task" || /security/sandbox/linux/SandboxInfo.cpp ||
|||||||| Failure to read and count number of files under this directory
causes tor browser to guess and indicate that it is not single threaded ||
|| mozilla::ComputeProcessUptimeThread(void*) || open ||
"/proc/self/task/$tid/stat", "/proc/self/stat" ||
/mozglue/misc/TimeStamp_posix.cpp ||
|||||||| This code fails gracefully and sets uptime to 0 ||
|| nsNotifyAddrListener::calculateNetworkId() || open ||
"/proc/net/route", "/proc/net/arp" ||
/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp ||
|||||||| This code fails gracefully, network id is only used once for
telemetry, otherwise this is dead code ||
|| js::GetNativeStackBaseImpl() || open || "/proc/self/maps" ||
/js/src/jsnativestack.cpp ||
|||||||| This code gets an address at the top of the usable stack,
required for internal JS stuff or else bad things happen. Attached patch
fixes this issue using !__libc_stack_end ||
|| mozilla::ThreadStackHelper::GetThreadStackBase() || open ||
"/proc/self/maps" || /xpcom/threads/ThreadStackHelper.cpp ||
|||||||| Similar to js::GetNativeStackBaseImpl() except the implementation
isn't there for all platforms and the saved value isn't used for anything,
fails gracefully ||
|| nsSystemInfo::Init() || open || "/proc/cpuino" ||
/xpcom/base/nsSystemInfo.cpp ||
|||||||| Fails gracefully, otherwise scrapes all your CPU info and stores
it in the nsISystemInfo property bag for god knows what reasons ||
|| gfxFcPlatformFontList::FindGenericFamilies() || readlink ||
"/proc/self/exe" || /gfx/thebes/gfxFcPlatformFontList.cpp ||
|||||||| Fails gracefully when intercepting this syscall and returning
error (-1) ||
|| nsLocalFile::GetDiskSpaceAvailable() || open || "/proc/self/mountinfo"
|| /xpcom/io/nsLocalFileUnix.cpp ||
|||||||| Fails gracefully when given file isn't found and a simpler
estimate is used instead ||
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20283#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs
mailing list