Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

changed milestone to %Tor: 0.3.5.x-final in legacy/trac

I think nickm understands the sandbox code the best.

Trac:
Points: N/A to 0.2
Status: new to assigned
Keywords: N/A deleted, crash, sandbox, linux, 040-must added
Milestone: N/A to Tor: 0.4.0.x-final
Owner: N/A to nickm

FWIW 5.0.2 worked AFAICT, so it is new in with 5.0.3

I've been trying to reproduce this but I've had no success so far.

Toralf, could you provide some more details. In particular, I'd be interested to know if …

… you have made and other modification to torrc but adding Sandbox 1.
… what operation system are you using.
… when the crash happens. (During startup, shutdown, randomly after a few minutes, etc.)

I also, wondered if you could provide debug logs. You should be able to get them by adding this to torrc:

Log debug file /var/log/tor/debug.log

I recommend you vet the logs for sensitive data before posting. The logs from just before the crash should be enough.

Trac:
Username: pege

This is a hardend Gentoo stable Linux with LibreSSL.

This issue seems not related to the minor upgdate of the kernel however. I do just wonder why it happened after booting into the new kernel but this issue is now reproducible with older kernel too. FWIW I had updated sys-firmware/intel-microcode and a sys-kernel/linux-firmware too around that time frame.

Fortunately it is easily repoducible both at my desktop and my server (same OS and versions, different CPU ofc):

t44 ~ # mkdir -p /tmp/tor; chown tor:root /tmp/tor; chmod 755 /tmp/tor/; cat ./torrc; date; /usr/bin/tor -f ./torrc 
User tor
PIDFile /tmp/tor/tor.pid
DataDirectory /tmp/tor/data

Log debug

CookieAuthentication 1
ControlPort 59051

SocksPort 59050

SandBox 1

Sun Mar 24 12:27:21 CET 2019
Mar 24 12:27:21.716 [notice] Tor 0.4.0.2-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.8.3, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 24 12:27:21.717 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 24 12:27:21.717 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 24 12:27:21.717 [notice] Read configuration file "/root/./torrc".
Mar 24 12:27:21.722 [notice] Opening Socks listener on 127.0.0.1:59050
Mar 24 12:27:21.722 [notice] Opened Socks listener on 127.0.0.1:59050
Mar 24 12:27:21.722 [notice] Opening Control listener on 127.0.0.1:59051
Mar 24 12:27:21.722 [notice] Opened Control listener on 127.0.0.1:59051
Mar 24 12:27:21.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Mar 24 12:27:21.000 [info] options_act_reversible(): Recomputed OOS thresholds: ConnLimit 1000, ConnLimit_ 4064, ConnLimit_high_thresh 4000, ConnLimit_low_thresh 3048
Mar 24 12:27:21.000 [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users.
Mar 24 12:27:21.000 [info] tor_lockfile_lock(): Locking "/tmp/tor/data/lock"
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 128.31.0.39:9131 (9695)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 86.59.21.38:80 (847B)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 194.109.206.212:80 (7EA6)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 16 dirserver at 66.111.2.131:9030 (BA44)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 131.188.40.189:80 (F204)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 193.23.244.244:80 (7BE6)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 171.25.193.9:443 (BD6A)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 154.35.175.225:80 (CF6D)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 199.58.81.140:80 (74A9)
Mar 24 12:27:21.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 204.13.164.118:80 (24E2)
Mar 24 12:27:21.000 [debug] file_status(): stat()ing /tmp/tor/data/state
Mar 24 12:27:21.000 [info] or_state_load(): Initialized state
Mar 24 12:27:21.000 [info] circuit_build_times_parse_state(): Adding 0 timeouts.
Mar 24 12:27:21.000 [info] circuit_build_times_parse_state(): Loaded 0/0 values from 0 lines in circuit time histogram
Mar 24 12:27:21.000 [debug] tor_rename(): Renaming /tmp/tor/data/state.tmp to /tmp/tor/data/state
Mar 24 12:27:21.000 [info] or_state_save(): Saved state to "/tmp/tor/data/state"
Mar 24 12:27:21.000 [info] read_file_to_str(): Could not open "/tmp/tor/data/router-stability": No such file or directory
Mar 24 12:27:21.000 [debug] tor_rename(): Renaming /tmp/tor/data/control_auth_cookie.tmp to /tmp/tor/data/control_auth_cookie
Mar 24 12:27:21.000 [info] init_cookie_authentication(): Generated auth cookie file in '"/tmp/tor/data/control_auth_cookie"'.
Mar 24 12:27:21.000 [debug] kist_scheduler_run_interval(): KISTSchedRunInterval=0, turning to the consensus.
Mar 24 12:27:21.000 [debug] scheduler_can_use_kist(): Determined KIST sched_run_interval should be 10. Can use KIST.
Mar 24 12:27:21.000 [info] scheduler_kist_set_full_mode(): Setting KIST scheduler with kernel support (KIST mode)
Mar 24 12:27:21.000 [debug] kist_scheduler_run_interval(): KISTSchedRunInterval=0, turning to the consensus.
Mar 24 12:27:21.000 [info] cmux_ewma_set_options(): Enabled cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in consensus; scale factor is 0.793701 per 10 seconds
Mar 24 12:27:21.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Mar 24 12:27:21.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Mar 24 12:27:21.000 [info] add_predicted_port(): New port prediction added. Will continue predictive circ building for 3502 more seconds.
Mar 24 12:27:21.000 [info] crypto_openssl_late_init(): NOT using OpenSSL engine support.
Mar 24 12:27:21.000 [info] evaluate_evp_for_aes(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.

============================================================ T= 1553426841
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x562c1224a5aa]
/lib64/libpthread.so.0(+0x14125)[0x7ff0aec2f125]
/lib64/libpthread.so.0(+0x14125)[0x7ff0aec2f125]
/usr/lib64/libevent-2.1.so.6(evsig_set_handler_+0xeb)[0x7ff0afb05f8b]
/usr/lib64/libevent-2.1.so.6(+0x2c0b6)[0x7ff0afb060b6]
/usr/lib64/libevent-2.1.so.6(evmap_signal_add_+0xb5)[0x7ff0afafeb55]
/usr/lib64/libevent-2.1.so.6(event_add_nolock_+0x74e)[0x7ff0afafa1ce]
/usr/lib64/libevent-2.1.so.6(event_add+0x3a)[0x7ff0afafa3fa]
/usr/bin/tor(handle_signals+0xa7)[0x562c120d30c7]
/usr/bin/tor(run_tor_main_loop+0x1a)[0x562c120d3c8a]
/usr/bin/tor(tor_run_main+0x1045)[0x562c120d4ea5]
/usr/bin/tor(tor_main+0x43)[0x562c120d23e3]
/usr/bin/tor(main+0x19)[0x562c120d1f99]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7ff0ae874ae7]
/usr/bin/tor(_start+0x2a)[0x562c120d1fea]

Trac:
strace.log

strace.log

I can reproduce this on gentoo as well.

This seems to be caused by the recent upgrade to libseccomp 2.4.0. Downgrading to 2.3.3 fixes the problem.

Trac:
Username: firebird

well, indeed I upgraded it:

libseccomp-2.4.0: Mon Mar 18 19:57:23 2019: 20 seconds

I can reproduce this now. Running Tor 0.3.5.8 on Fedora 29 with libseccomp 0.2.4.

The sandbox violation appears to be in libevent (signal.c:258)

I'll try to find some time in the next few days to track down the issue. I've no clue yet why this should behave differently with libseccomp 0.2.4.

[user@repro-seccomp ~]$ sudo -u toranon gdb tor
...
Reading symbols from tor...Reading symbols from /usr/lib/debug/usr/bin/tor-0.3.5.8-1.fc29.x86_64.debug...done.
done.
(gdb) r
Starting program: /usr/bin/tor 
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
Mar 24 22:30:52.707 [notice] Tor 0.3.5.8 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1b, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Mar 24 22:30:52.707 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 24 22:30:52.707 [notice] Read configuration file "/etc/tor/torrc".
Mar 24 22:30:52.709 [notice] Opening Socks listener on 127.0.0.1:9050
Mar 24 22:30:52.709 [notice] Opened Socks listener on 127.0.0.1:9050
Mar 24 22:30:52.709 [notice] Opening Control listener on /run/tor/control
Mar 24 22:30:52.709 [notice] Opened Control listener on /run/tor/control
Mar 24 22:30:52.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Mar 24 22:30:52.000 [info] options_act_reversible(): Recomputed OOS thresholds: ConnLimit 1000, ConnLimit_ 4064, ConnLimit_high_thresh 4000, ConnLimit_low_thresh 3048
Mar 24 22:30:52.000 [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users.
Mar 24 22:30:52.000 [info] tor_lockfile_lock(): Locking "/var/lib/tor/.tor/lock"
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 128.31.0.39:9131 (9695)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 86.59.21.38:80 (847B)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 194.109.206.212:80 (7EA6)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 16 dirserver at 66.111.2.131:9030 (BA44)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 131.188.40.189:80 (F204)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 193.23.244.244:80 (7BE6)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 171.25.193.9:443 (BD6A)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 154.35.175.225:80 (CF6D)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 199.58.81.140:80 (74A9)
Mar 24 22:30:52.000 [debug] parse_dir_authority_line(): Trusted 100 dirserver at 204.13.164.118:80 (24E2)
Mar 24 22:30:52.000 [debug] file_status(): stat()ing /var/lib/tor/.tor/state
Mar 24 22:30:52.000 [info] or_state_load(): Loaded state from "/var/lib/tor/.tor/state"
Mar 24 22:30:52.000 [info] circuit_build_times_parse_state(): Adding 0 timeouts.
Mar 24 22:30:52.000 [info] circuit_build_times_parse_state(): Loaded 0/0 values from 0 lines in circuit time histogram
Mar 24 22:30:52.000 [info] read_file_to_str(): Could not open "/var/lib/tor/.tor/router-stability": No such file or directory
Mar 24 22:30:52.000 [debug] tor_rename(): Renaming /run/tor/control.authcookie.tmp to /run/tor/control.authcookie
Mar 24 22:30:52.000 [info] init_cookie_authentication(): Generated auth cookie file in '"/run/tor/control.authcookie"'.
Mar 24 22:30:52.000 [debug] kist_scheduler_run_interval(): KISTSchedRunInterval=0, turning to the consensus.
Mar 24 22:30:52.000 [debug] scheduler_can_use_kist(): Determined KIST sched_run_interval should be 10. Can use KIST.
Mar 24 22:30:52.000 [info] scheduler_kist_set_full_mode(): Setting KIST scheduler with kernel support (KIST mode)
Mar 24 22:30:52.000 [debug] kist_scheduler_run_interval(): KISTSchedRunInterval=0, turning to the consensus.
Mar 24 22:30:52.000 [info] cmux_ewma_set_options(): Enabled cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in consensus; scale factor is 0.793701 per 10 seconds
Mar 24 22:30:52.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Mar 24 22:30:52.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Mar 24 22:30:52.000 [info] add_predicted_port(): New port prediction added. Will continue predictive circ building for 2807 more seconds.
Mar 24 22:30:52.000 [info] crypto_openssl_late_init(): NOT using OpenSSL engine support.
Mar 24 22:30:52.000 [info] evaluate_evp_for_aes(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.

Program received signal SIGSYS, Bad system call.
0x00007ffff7879104 in __libc_sigaction (sig=sig@entry=1, act=act@entry=0x7fffffffe100, oact=0x5555560f8db0)
    at ../sysdeps/unix/sysv/linux/sigaction.c:58
58	  result = INLINE_SYSCALL_CALL (rt_sigaction, sig,
Missing separate debuginfos, use: dnf debuginfo-install libseccomp-2.4.0-0.fc29.x86_64
(gdb) bt
#0  0x00007ffff7879104 in __libc_sigaction (sig=sig@entry=1, act=act@entry=0x7fffffffe100, oact=0x5555560f8db0)
    at ../sysdeps/unix/sysv/linux/sigaction.c:58
#1  0x00007ffff7879239 in __sigaction (sig=sig@entry=1, act=act@entry=0x7fffffffe100, oact=<optimized out>)
    at ../nptl/sigaction.c:30
#2  0x00007ffff7def062 in evsig_set_handler_ (base=base@entry=0x5555558808a0, evsignal=evsignal@entry=1, 
    handler=handler@entry=0x7ffff7deec20 <evsig_handler>) at signal.c:258
#3  0x00007ffff7def1dc in evsig_add (base=0x5555558808a0, evsignal=1, old=<optimized out>, 
    events=<optimized out>, p=<optimized out>) at signal.c:302
#4  0x00007ffff7de76f5 in evmap_signal_add_ (base=base@entry=0x5555558808a0, sig=<optimized out>, 
    ev=ev@entry=0x55555587cf90) at evmap.c:457
#5  0x00007ffff7de27be in event_add_nolock_ (ev=ev@entry=0x55555587cf90, tv=tv@entry=0x0, 
    tv_is_absolute=tv_is_absolute@entry=0) at event.c:2602
#6  0x00007ffff7de2a8e in event_add (ev=0x55555587cf90, tv=tv@entry=0x0) at event.c:2445
#7  0x00005555555acd6f in handle_signals () at src/app/main/main.c:508
#8  0x00005555555ad9df in run_tor_main_loop () at src/app/main/main.c:1275
#9  0x00005555555aee85 in tor_run_main (tor_cfg=tor_cfg@entry=0x555555852950) at src/app/main/main.c:1484
#10 0x00005555555ac07e in tor_main (argc=1, argv=0x7fffffffe528) at src/feature/api/tor_api.c:164
#11 0x00005555555abc0d in main (argc=<optimized out>, argv=<optimized out>) at src/app/main/tor_main.c:32
(gdb) l
53	      SET_SA_RESTORER (&kact, act);
54	    }
55	
56	  /* XXX The size argument hopefully will have to be changed to the
57	     real size of the user-level sigset_t.  */
58	  result = INLINE_SYSCALL_CALL (rt_sigaction, sig,
59					act ? &kact : NULL,
60					oact ? &koact : NULL, STUB(act) _NSIG / 8);
61	
62	  if (oact && result >= 0)
(gdb) f 1
#1  0x00007ffff7879239 in __sigaction (sig=sig@entry=1, act=act@entry=0x7fffffffe100, oact=<optimized out>)
    at ../nptl/sigaction.c:30
30	  return __libc_sigaction (sig, act, oact);
(gdb) l
25	    {
26	      __set_errno (EINVAL);
27	      return -1;
28	    }
29	
30	  return __libc_sigaction (sig, act, oact);
31	}
32	libc_hidden_weak (__sigaction)
33	weak_alias (__sigaction, sigaction)
(gdb) f 2
#2  0x00007ffff7def062 in evsig_set_handler_ (base=base@entry=0x5555558808a0, evsignal=evsignal@entry=1, 
    handler=handler@entry=0x7ffff7deec20 <evsig_handler>) at signal.c:258
258		if (sigaction(evsignal, &sa, sig->sh_old[evsignal]) == -1) {
(gdb) l
253		memset(&sa, 0, sizeof(sa));
254		sa.sa_handler = handler;
255		sa.sa_flags |= SA_RESTART;
256		sigfillset(&sa.sa_mask);
257	
258		if (sigaction(evsignal, &sa, sig->sh_old[evsignal]) == -1) {
259			event_warn("sigaction");
260			mm_free(sig->sh_old[evsignal]);
261			sig->sh_old[evsignal] = NULL;
262			return (-1);

Trac:
Username: pege
Cc: N/A to peter@arbitrary.ch
Summary: Linux kernel 5.0.3 crashes sandbox configured Tor client to Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4
Version: Tor: 0.4.0.2-alpha to Tor: unspecified

evsignal in the code above is 1 which would make the signal SIGHUP:

(gdb) print evsignal
$1 = 1

Looking at sandbox.c:305, however, that signal should be allowed.

Trac:
Username: pege

Are you sure that line is reached? All I can think of here is the possibility that maybe that rule is never added to the sandbox due to some kind of programming error or change in libseccomp2. Can you double-check that we really reaach sandbox.c:305 with param[i]==SIGHUP?

never mind -- I managed to reproduce the bug, and it is clear that line is being reached. I suspect a bug in libseccomp.

I used "git bisect" on libseccomp, and it says "cf98f79d0894221beb9f2753c092304237617c1c" is the first bad commit. Here is my log:

git bisect start
# bad: [7fbf639526eb37a011318736587c3a6f8206b888] all: update the CHANGELOG and version for v2.4.0
git bisect bad 7fbf639526eb37a011318736587c3a6f8206b888
# good: [74b190e1aa05f07da0c61fb9a30dbc9c18ce2c9d] build: bump the version to v2.3.3
git bisect good 74b190e1aa05f07da0c61fb9a30dbc9c18ce2c9d
# good: [bbf23ba4beae9a23148c6845a3037b1a4a8589e7] doc: update the CHANGELOG for the v2.3.0 release
git bisect good bbf23ba4beae9a23148c6845a3037b1a4a8589e7
# good: [94d92b39d17dc5546a5e947d042584dbc79decb1] man: Fix SCMP_FLTATR_API_TSKIP typo in seccomp_attr_set man page
git bisect good 94d92b39d17dc5546a5e947d042584dbc79decb1
# bad: [85cde70d0162c000dd4fc108b0ab0149c113c643] all: fixup all the file permissions
git bisect bad 85cde70d0162c000dd4fc108b0ab0149c113c643
# good: [56250ddff8fd78f6eaa3a0e0a01dfff01093212f] doc: update the CHANGELOG and CREDITS for v2.3.3
git bisect good 56250ddff8fd78f6eaa3a0e0a01dfff01093212f
# good: [a2c104da83856136547eb1e8f33b4c194a0fe945] doc: update the coveralls badge to use shields.io
git bisect good a2c104da83856136547eb1e8f33b4c194a0fe945
# bad: [cf98f79d0894221beb9f2753c092304237617c1c] db: applied pcmoore's gist for GH issue #112
git bisect bad cf98f79d0894221beb9f2753c092304237617c1c
# good: [43d78737f323e0b87d21c2a5678b46ff26b00e30] docs: add golang bindings pointer to README.md
git bisect good 43d78737f323e0b87d21c2a5678b46ff26b00e30
# good: [c14558ec0c8edcd92974adba43543d2d4f20e7f1] docs: add the supported ABIs to the README
git bisect good c14558ec0c8edcd92974adba43543d2d4f20e7f1
# first bad commit: [cf98f79d0894221beb9f2753c092304237617c1c] db: applied pcmoore's gist for GH issue #112

Looking at the libseccomp patch in question, I'm not seeing any obvious problems. Can anybody else try bisecting libseccomp here to see if they get the same result?

Bisecting libseccomp has been on my todo list anyway. So, I should be able to verify your result. I don't expect to get to it before Tuesday though.

Trac:
Username: pege

This is from upstream:

https://github.com/seccomp/libseccomp/issues/148#issuecomment-478127562

It appears that the libseccomp folks now believe this is a bug on their end.

Removing 040-must, since this is a libseccomp bug.

Trac:
Keywords: 040-must deleted, N/A added

Short update. The issue initially reported is on the way of being resolved. BPF is now generated correctly for the sigaction() call mentioned in an earlier comment.

This fix, however, is not enough to get Tor working with libseccomp v2.4.0. This version contains some major correction when it comes to BPF generation. In particular, earlier versions could generate BPF code that did not enforce all rules correctly. It would appear that PBF code was indeed generated incorrectly in case of Tor which lead to some bugs in Tor's sandbox implementation going unnoticed. In particular, file names passed to open(), openat() and rename() appear to be affected.

See my comment on libseccomps bug tracker. Response from the libseccomp maintainers is a bit further down.

I'll look at Tor sandbox a bit closer on the weekend in the hope of coming up with a way to deal with the issue. I guess we'll need some way of making sure paths are stored at fixed memory locations by either computing all the paths during compilation or during startup and then revoke write permission somehow for that region of memory the contains them.

Trac:
Username: pege

I guess we'll need some way of making sure paths are stored at fixed memory locations by either computing all the paths during compilation or during startup and then revoke write permission somehow for that region of memory the contains them.

We do that currently; see sandbox.c functions sandbox_intern_string() and prot_strings()

Thanks, nickm, for the pointers. Still trying to understand how the sandbox works.

I went through all the comments on GitHub again and I think this comment regarding an earlier comment could explain the issue. At least when also considering this comment that hints that there is not really a fixed order in which rules are applied. I guess merging path checks and flag checks may be worth a try. I'll try exactly that on the weekend unless someone wants to do that now.

Trac:
Username: pege

Looks like Tor used libseccomp in a way it was never intended to be used. See this comment and the response here.

Nickm, I think you know the Sandbox better than I do. Where do we go from here? I'd say we just return EPERM whenever we want to deny access. I'd expect this to be least likely to introduce any regressions. If we just fail with SIGSYS, this is likely to break on one system or another. On Fedora, at least OpenSSL attemps to open file that's not allowed, namely, /etc/crypto-policies/back-ends/openssl.config. We can always decide to switch to SYSSIG later on, after thorough testing but I think first we should make sure no more installations break because of a libseccomp v2.4.0 upgrade.

Trac:
Username: pege

I applied the 2.4.0..2.4.1 diff here at a stable Gentoo hardened and got not

t44 /etc/portage/patches/sys-libs/libseccomp-2.4.0 # tail -f /tmp/notice.log 
Apr 18 16:40:34.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Apr 18 16:40:34.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Apr 18 16:40:34.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Apr 18 16:40:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 18 16:40:34.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Apr 18 16:40:34.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Permission denied
Apr 18 16:40:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 18 16:40:44.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.
Apr 18 16:40:47.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.
Apr 18 16:40:47.000 [notice] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.

The perms are right IMO:

t44 /etc/portage/patches/sys-libs/libseccomp-2.4.0 # ls -l /var/lib/tor/data/
total 12108
-rw------- 1 tor tor   20442 Apr 18 16:40 cached-certs
-rw------- 1 tor tor 2110905 Apr 18 16:16 cached-microdesc-consensus
-rw------- 1 tor tor 5965233 Apr 11 18:20 cached-microdescs
-rw------- 1 tor tor 2163133 Apr 18 16:17 cached-microdescs.new
-rw------- 1 tor tor      32 Apr 18 16:40 control_auth_cookie
drwx------ 1 tor tor     224 Aug 18  2017 keys
-rw------- 1 tor tor       0 Apr 18 16:40 lock
-rw------- 1 tor tor   12212 Apr 18 16:40 state
-rw------- 1 tor tor 2111522 Apr 18 16:40 unverified-microdesc-consensus

I do wonder if this is a new bug uncovered b/c libseccomp has fixed its issue?

pege -- the EPERM idea seems plausible, if it works. Do you have time to try it out?

Otherwise, the only workable idea I can think of is to rearchitect how we handle filesystem interactions in the sandbox. We should really have an trusted unsandboxed process whose job it is to open files for the main process, and pass them back over a pipe. This would let us support more sandboxing techniques, and allow us to throw out our immutable-string hacks. It would be a lot of work though, and I don't see where we have time to do it in our current roadmap.

Trac:
Points: 0.2 to 2-10

pege -- the EPERM idea seems plausible, if it works. Do you have time to try it out?

I should have some time to try this this weekend. I'll let you know how it is going.

Otherwise, the only workable idea I can think of is to rearchitect how we handle filesystem interactions in the sandbox. We should really have an trusted unsandboxed process whose job it is to open files for the main process, and pass them back over a pipe. This would let us support more sandboxing techniques, and allow us to throw out our immutable-string hacks. It would be a lot of work though, and I don't see where we have time to do it in our current roadmap.

Moving file handling to some kind of broker running in an unsandboxed process is the proper solution here I'd say but that'll take some time. Let's see how EPERM works out first. The only issue I can see with the sandbox is that mmap()ing files to save memory will no longer be possible. Consider the security benefit, it's probably a minor issue though.

I wonder if there isn't some third party library for creating a broker, handling permissions and passing content to the sandboxed process. If not, I'm thinking this could make a good project for introducing some more Rust. I guess the broker itself could be written in Rust completely.

Trac:
Username: pege

Took a bit longer for me to get to test this but finally I found some time. So, as discussed (much) earlier, I created a patch to deny syscalls by means of EPERM (https://gitlab.com/pgerber/tor/commits/bug29819-2).

I did some testing, in particular I've run my patch on an exit relay, on an non-exit relay, as a hidden service provider and as a client for some time. I came across some issues when reloading the config but couldn't find anything that worked before and broke or changed in behavior because of my patch or the update to libseccomp v0.2.4.

Trac:
Username: pege

Trac:
Status: assigned to needs_review
Milestone: Tor: 0.4.0.x-final to Tor: 0.4.3.x-final

Trac:
Reviewer: N/A to nickm

Thanks! This approach looks potentially sound to me.

I've made a backport branch as bug29819_035 with a PR as https://github.com/torproject/tor/pull/1614.

I've made a branch merging that to master as bug29819_043 with a PR as https://github.com/torproject/tor/pull/1613 . The merge is clean; this is just for CI.

Trac:
Keywords: sandbox deleted, sandbox 035-backport 041-backport 042-backport added

This works for me on at least one platform where seccomp previously didn't work. Let's see how our CI does.

Trac:
Cc: peter@arbitrary.ch to peter@arbitrary.ch, teor

Trac:
Keywords: N/A deleted, consider-backport-after-0431 added

Should we be running some of our CI across different platforms?

Travis has Precise, Trusty, Xenial, and Bionic: https://docs.travis-ci.com/user/reference/linux#overview

Xenial and Bionic are still supported. Trusty is only supported for paid Ubuntu customers. https://ubuntu.com/about/release-cycle

I'm okay with merging this into master, and getting some experience before we backport.

Teor, please let me know if you would like to do more CI here before I merge.

Trac:
Status: needs_review to merge_ready

I don't think sandbox CI is an option right now. We know the sandbox fails on Ubuntu Bionic and Xenial, and Tor master soon won't run on Trusty, because we're removing support for OpenSSL < 1.1.1.

Okay. Let's try it out in 0.4.3 and see how it goes.

Merging to master; marking for backport.

Trac:
Milestone: Tor: 0.4.3.x-final to Tor: 0.4.2.x-final

I cherrypicked commit 0d64bafc and applied it at the affected Tor relay running 0.4.2.5 (hardened Gentoo Linux).

It seems to work, Tor starts for both relays and and even more survives a change in a config file located under /etc/tor/torrc.d/.

Merged to 0.3.5 and later.

Merged with legacy/trac#32778 (moved).

Trac:
Milestone: Tor: 0.4.2.x-final to Tor: 0.3.5.x-final
Status: merge_ready to closed
Resolution: N/A to fixed
Actualpoints: N/A to 0.3
Keywords: sandbox 035-backport 041-backport 042-backport deleted, sandbox 035-backport 041-backport 042-backport BugSmashFund added
Version: Tor: unspecified to Tor: 0.2.5.1-alpha
Points: 2-10 to N/A

closed

added 2h 24m of time spent

mentioned in issue legacy/trac#32778 (moved)

mentioned in issue legacy/trac#34130 (moved)

moved from legacy/trac#29819 (moved)

added Bug label and removed 1 deleted label

added Crash label and removed 1 deleted label

added BugSmashFund label

Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

Child items 0

Activity