Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34133Tor documentation missing sandbox and %include limitations2020-06-13T15:53:28ZJigsaw52Tor documentation missing sandbox and %include limitationsThe tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.The tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23706Tor's seccomp sandbox does not know about the syscall epoll_pwait2020-06-13T15:14:56ZcypherpunksTor's seccomp sandbox does not know about the syscall epoll_pwaitI was playing with the seccomp sandbox with tor 3.2.1-alpha.
The system in question uses Musl as the standard C library. When adding "Sandbox 1" to a minimal torrc (attached at the end), this results in an error, saying "(Sandbox) Caugh...I was playing with the seccomp sandbox with tor 3.2.1-alpha.
The system in question uses Musl as the standard C library. When adding "Sandbox 1" to a minimal torrc (attached at the end), this results in an error, saying "(Sandbox) Caught a bad syscall attempt (syscall epoll_pwait)".
The operating system is Gentoo, and the kernel version is 4.9.24-grsec. It is reproducible on Alpine Linux (which also uses Musl as standard C library), but not on Debian, which suggests this is due to Musl exposing an extra system call to Tor that the sandbox does not recognize.
It's also reproducible on tor-0.3.1.7, which suggests this is not a new defect for the 3.2.x series.
The minimal torrc for which this is reproducible is as follows:
User tor
Log debug file /var/log/tor/tor.log
DataDirectory /var/lib/tor/data
Sandbox 1Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22516tor fails to start with 'Sandbox 1'2020-06-13T15:10:03Zcypherpunkstor fails to start with 'Sandbox 1'OS: CentOS 7
SELinux: disabled
tor-0.2.9.10-1.el7.x86_64
```
============================================================
(Sandbox) Caught a bad syscall attempt (syscall fchmod)
/usr/bin/tor(+0x15d83a)[0x7ff9aa58b83a]
/lib64/libc.s...OS: CentOS 7
SELinux: disabled
tor-0.2.9.10-1.el7.x86_64
```
============================================================
(Sandbox) Caught a bad syscall attempt (syscall fchmod)
/usr/bin/tor(+0x15d83a)[0x7ff9aa58b83a]
/lib64/libc.so.6(fchmod+0x7)[0x7ff9a8b1a917]
/lib64/libc.so.6(fchmod+0x7)[0x7ff9a8b1a917]
/usr/bin/tor(check_private_dir+0x151)[0x7ff9aa584741]
/usr/bin/tor(init_keys+0x9b)[0x7ff9aa4b6cab]
/usr/bin/tor(do_main_loop+0x4b)[0x7ff9aa472b1b]
/usr/bin/tor(tor_main+0x1c25)[0x7ff9aa4763a5]
/usr/bin/tor(main+0x19)[0x7ff9aa46e8c9]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff9a8a53b35]
/usr/bin/tor(+0x4091b)[0x7ff9aa46e91b]
```
torrc:
```
OfflineMasterKey 1
RunAsDaemon 0
Log notice syslog
OutboundBindAddress ...
SocksPort 0
User ...
DataDirectory /var/lib/tor-instances/...
ORPort ...
DirPort ...
SyslogIdentityTag ...
Nickname ...
ControlSocket 0
CookieAuthentication 0
ExitRelay 0
ExitPolicy reject *:*
Sandbox 1
ShutdownWaitLength 1
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18397`Sandbox 1` in Tor 0.2.7.6 should not filter `getsockopt` syscall2020-06-13T14:54:48ZTrac`Sandbox 1` in Tor 0.2.7.6 should not filter `getsockopt` syscallIn Tor version 0.2.7.6 (git-605ae665009853bd) on Debian sid, setting `Sandbox 1` in `torrc` filters the `getsockopt` syscall, which is necessary for applications such as torsocks, xmpp-client, and TorBirdy. This syscall should be re-un-b...In Tor version 0.2.7.6 (git-605ae665009853bd) on Debian sid, setting `Sandbox 1` in `torrc` filters the `getsockopt` syscall, which is necessary for applications such as torsocks, xmpp-client, and TorBirdy. This syscall should be re-un-blacklisted from the seccomp policy. I say 're' because I confirmed it works in Debian Jessie running version 0.2.7.6-1~d80.jessie+1.
**Trac**:
**Username**: fowlslegsTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16160seccomp sandbox does not work on arm2020-06-13T14:46:27ZTracseccomp sandbox does not work on armTor v0.2.6.8 as shipped by arch linux arm (armv6h/raspberry pi) crashes when the seccomp sandbox is enabled with the following error:
```
============================================================ T= 1432314730
(Sandbox) Caught a bad s...Tor v0.2.6.8 as shipped by arch linux arm (armv6h/raspberry pi) crashes when the seccomp sandbox is enabled with the following error:
```
============================================================ T= 1432314730
(Sandbox) Caught a bad syscall attempt (syscall 289)
/usr/bin/tor(+0x13f734)[0xb6ee7734]
/usr/lib/libc.so.6(__send+0x1c)[0xb69ac7ec]
/usr/lib/libc.so.6(__send+0x1c)[0xb69ac7ec]
```
I started looking into the code and came up with the attached patch. Afterwards the error message is this:
```
============================================================ T= 1432331214
(Sandbox) Caught a bad syscall attempt (syscall eventfd2)
/usr/bin/tor(+0x1402e4)[0xb6ef02e4]
/usr/lib/libc.so.6(eventfd+0xc)[0xb696ca5c]
/usr/lib/libc.so.6(eventfd+0xc)[0xb696ca5c]
/usr/bin/tor(alert_sockets_create+0x98)[0xb6eda974]
/usr/bin/tor(replyqueue_new+0x3c)[0xb6ef43c4]
/usr/bin/tor(cpu_init+0xc4)[0xb6ea1360]
/usr/bin/tor(do_main_loop+0x358)[0xb6dd9cac]
/usr/bin/tor(tor_main+0x160)[0xb6ddb744]
```
Since I'm neither familiar with seccomp nor the tor codebase, this is where I gave up… I hope someone here can fix this.
**Trac**:
**Username**: ajs124Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15088Add the wait4() syscall to the seccomp sandbox2020-06-13T14:43:55ZTracAdd the wait4() syscall to the seccomp sandboxTor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
====...Tor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
============================================================ T= 1425215692
(Sandbox) Caught a bad syscall attempt (syscall wait4)
/usr/bin/tor(+0x12f4f1)[0x4273cf44f1]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/usr/bin/tor(notify_pending_waitpid_callbacks+0x4a)[0x4273cf42da]
/usr/bin/tor(process_signal+0x4ad)[0x4273bfb96d]
/usr/lib64/libevent-2.0.so.5(event_base_loop+0x99e)[0x3423a111a6e]
/usr/bin/tor(do_main_loop+0x1ad)[0x4273bfa77d]
/usr/bin/tor(tor_main+0x1875)[0x4273bfd755]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x342394e2d55]
/usr/bin/tor(+0x31c49)[0x4273bf6c49]
Mar 01 16:14:52.000 [info] cpuworker_main(): read request failed. Exiting.
```
The patch is as simple as adding wait4() to the whitelist:
```
diff -Naur tor-0.2.5.10/src/common/sandbox.c tor-0.2.5.10.new/src/common/sandbox.c
--- tor-0.2.5.10/src/common/sandbox.c
+++ tor-0.2.5.10.new/src/common/sandbox.c
@@ -119,6 +119,7 @@
SCMP_SYS(epoll_wait),
SCMP_SYS(fcntl),
SCMP_SYS(fstat),
+ SCMP_SYS(wait4),
#ifdef __NR_fstat64
SCMP_SYS(fstat64),
#endif
```
**Trac**:
**Username**: sanicTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9730GSOC seccomp stage 32020-06-13T14:31:56ZTracGSOC seccomp stage 3Review and merge phase 3 of seccomp capabilities filtering.
This version aims to restrict the libseccomp filter by dropping privileges in different sections of the code, in an attempt to make the sandbox as restrictive as possible.
Rem...Review and merge phase 3 of seccomp capabilities filtering.
This version aims to restrict the libseccomp filter by dropping privileges in different sections of the code, in an attempt to make the sandbox as restrictive as possible.
Remote: https://github.com/cristiantoader/tor-gsoc-capabilities
Branch: gsoc-cap-stage3
Quick link: https://github.com/cristiantoader/tor-gsoc-capabilities/tree/gsoc-cap-stage3
**Trac**:
**Username**: ctoaderTor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/9249GSOC seccomp stage 22020-06-13T14:30:21ZTracGSOC seccomp stage 2Review and merge phase 2 of seccomp capabilities filtering.
This version should implement much more restrictive filtering, mostly based on parameter filtering of the syscalls.
Remote: https://github.com/cristiantoader/tor-gsoc-capabili...Review and merge phase 2 of seccomp capabilities filtering.
This version should implement much more restrictive filtering, mostly based on parameter filtering of the syscalls.
Remote: https://github.com/cristiantoader/tor-gsoc-capabilities
Branch: gsoc-cap-stage2
**Trac**:
**Username**: ctoaderNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/9168GSOC seccomp stage 12020-06-13T14:30:07ZTracGSOC seccomp stage 1Review and merge phase 1 of seccomp work.
Remote branch: https://github.com/cristiantoader/tor-gsoc-capabilities
**Trac**:
**Username**: ctoaderReview and merge phase 1 of seccomp work.
Remote branch: https://github.com/cristiantoader/tor-gsoc-capabilities
**Trac**:
**Username**: ctoaderTor: 0.2.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5756Seccomp system call whitelisting on Linux2020-06-13T14:19:24ZTracSeccomp system call whitelisting on LinuxThis is a feature request/suggestion that applies to the Linux-compatible software developed as part of the Tor project such as Tor and obfsproxy.
Recently Will "redpig" Drewry released his seccomp patch that allows processes to describ...This is a feature request/suggestion that applies to the Linux-compatible software developed as part of the Tor project such as Tor and obfsproxy.
Recently Will "redpig" Drewry released his seccomp patch that allows processes to describe a policy for which system calls the binary should be allowed to call during execution.
After the policy is finalized, the kernel will match syscalls against the policy, limiting what an attacker can do in the event of a compromise.
Be aware that this new patch is different from the original "seccomp" patch submitted by the Chrome project.
The old patch had a static whitelist of syscalls, this new one allows dynamic policy construction upon execution and also allows the programmer to define policies for the parameters passed to the syscalls.
Here are some related links:
http://outflux.net/teach-seccomp/
https://github.com/redpig/linux
http://sourceforge.net/projects/libseccomp/
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=blob;f=Documentation/prctl/seccomp_filter.txt;hb=HEAD
http://scarybeastsecurity.blogspot.fr/2012/04/vsftpd-300-and-seccomp-filter.html
Ubuntu 12.04 (the most recent LTS release) comes integrated with this patch and it seems like there are good chances the patch will go upstream.
We should consider the possibility of using it for current and future projects that could benefit from sandboxing.
Chrome decided to use the original seccomp prctl option in their rendering processes which their "privileged" code then talks to using an inherited file descriptor.
If we cannot define a sufficiently strict policy for the entire process, we should consider putting as much functionality as possible into a confined process to limit our attack surface.
I am not sure if this belongs here as a feature request or on a mailing-list, but I would like to see some discussion about the feasibility of using this sandboxing feature for the Linux builds.
**Trac**:
**Username**: bugmenotTor: 0.2.5.x-final