Tor Browser should run without a `/proc` filesystem.
Currently Tor Browser crashes immediately on startup if a proc filesystem is not mounted on /proc. This also affects the upstream firefox code, so it technically is a Mozilla bug.
too much recursion
Segmentation fault (core dumped)/proc contains a large amount of information about the host system that can be used to fingerprint/identify users and additionally historically has been the source or part of many kernel security problems.
While this problem can be mitigated by a MAC system (eg: AppArmor) to constrain what Firefox can access under /proc, the ideal fix is for Firefox to support running without /proc, while degrading gracefully (there is no truly ubiquitous MAC system available on all common Linux distributions by default, and the problem is severe enough that it should be resolved correctly).
Activity
Trac:
Parent: N/A to #20773 (closed)Upstream (Old): https://bugzilla.mozilla.org/show_bug.cgi?id=859782
There are at least two issues that I know of that prevent running Firefox without
/procmounted.The first is that Firefox uses
/proc/self/taskto see if it spawned any threads. The warning can be ignored on any kernel that supportsSECCOMP_FILTER_FLAG_TSYNC(>= 3.17), but may result in "bad" if the kernel is old, and no, I do not remember what the bad is.The second is that Firefox will crash with
too much recursionif/procis not mounted. The culprit there is that Firefox will query the stack size withpthread_attr_getstack()which will return a stack size of0, if/procis not mounted for the default thread (tid == pid).Note that there may be other horrific things that happen, or other things that break without
/proc, but I was not able to find any at the time that I cared about this. Finding and debugging such things is left as an exercise for the student. Fixing this properly probably requires upstream to care about this use case.
If
SECCOMP_FILTER_FLAG_TSYNCisn't available and/proc/self/taskcan't be listed, the sandbox can't start. The process is already multithreaded, so we have to signal all the threads to tell them to apply seccomp, and we don't have access to the libc's internal list of threads (or the lock protecting it) so we have to ask the kernel via procfs.The single-threadedness check, however, has been removed in Firefox 60, as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1401062.
Trac:
Username: jld
I've identified all (hopefully) the callers in the parent firefox and the child plugin_container (nothing unique in plugin_container though that isn't called in the parent). The spawned glxtest also has lots of reads going to /proc as well.
For patch verification, what's the procedure for hiding /proc from a process in general?
Replying to jld:
If
SECCOMP_FILTER_FLAG_TSYNCisn't available and/proc/self/taskcan't be listed, the sandbox can't start. The process is already multithreaded, so we have to signal all the threads to tell them to apply seccomp, and we don't have access to the libc's internal list of threads (or the lock protecting it) so we have to ask the kernel via procfs.The single-threadedness check, however, has been removed in Firefox 60, as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1401062.
That's actually #23915 (closed) and we should be good with that.
-
Replying to pospeselr:
I've identified all (hopefully) the callers in the parent firefox and the child plugin_container (nothing unique in plugin_container though that isn't called in the parent). The spawned glxtest also has lots of reads going to /proc as well.
For patch verification, what's the procedure for hiding /proc from a process in general?
I don't know but you could mess with Yawning's
sandboxed-tor-browser(which brought this issue up in the first place), see: #20773 (closed) and the patch for it in 95857360ec7f84cf9f0a01855c15881c89919133. From conversation with pospeselr:
I suspect that glibc relies on /proc only for the initial thread. It is possible that for the initial thread you can get the stack base address and size using getcontext(2). In particular, if pthread_getattr_np fails or pthread_attr_getstack returns null, and the thread in question is the process's initial thread, then it is possible that
ucontext_t uc; void *base; size_t size; if (getcontext(&uc) == -1) err(1, "getcontext"); base = uc.uc_stack.ss_sp; size = uc.uc_stack.ss_size;will recover the stack base address and size that you want.
Replying to cypherpunks:
I suspect that glibc relies on /proc only for the initial thread.
Yes.
it is possible that
{{{ ucontext_t uc; void *base; size_t size;
if (getcontext(&uc) == -1) err(1, "getcontext"); base = uc.uc_stack.ss_sp; size = uc.uc_stack.ss_size; }}}
will recover the stack base address and size that you want.
99% sure this does not work without /proc mounted.
-
As mentioned by cypherpunks, the issue here only occurs on the main thread which you can verify with a little spelunking through the glibc source. The relevant query APIs work expected on non-main threads since pthreads populates the required info in memory.
Verifying a patch now on TreeHerder that fixes this issue by reading the !__libc_stack_end symbol (glibc sets this void* to the first stack frame during program init). Solution suggested by mozilla's jld, and the folks in #jsapi (those paying attention at least) didn't seem offended at the idea of doing so for the main thread.
