Opened 2 months ago

Last modified 11 days ago

#29819 assigned defect

Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

Reported by: toralf Owned by: nickm
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: crash, linux, sandbox
Cc: peter@… Actual Points:
Parent ID: Points: 2-10
Reviewer: Sponsor:

Description

With Sandbox=1 I do get with the new stable Vanilla Linux kernel

============================================================ T= 1553016509
(Sandbox) Caught a bad syscall attempt (syscall rt_sigaction)
/usr/bin/tor(+0x1ce5aa)[0x5636adfa15aa]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/lib64/libpthread.so.0(+0x14125)[0x7f0d99074125]
/usr/lib64/libevent-2.1.so.6(evsig_set_handler_+0xeb)[0x7f0d99f4df8b]
/usr/lib64/libevent-2.1.so.6(+0x2c0b6)[0x7f0d99f4e0b6]
/usr/lib64/libevent-2.1.so.6(evmap_signal_add_+0xb5)[0x7f0d99f46b55]
/usr/lib64/libevent-2.1.so.6(event_add_nolock_+0x74e)[0x7f0d99f421ce]
/usr/lib64/libevent-2.1.so.6(event_add+0x3a)[0x7f0d99f423fa]
/usr/bin/tor(handle_signals+0xa7)[0x5636ade2a0c7]
/usr/bin/tor(run_tor_main_loop+0x1a)[0x5636ade2ac8a]
/usr/bin/tor(tor_run_main+0x1045)[0x5636ade2bea5]
/usr/bin/tor(tor_main+0x43)[0x5636ade293e3]
/usr/bin/tor(main+0x19)[0x5636ade28f99]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7f0d98cb9ae7]
/usr/bin/tor(_start+0x2a)[0x5636ade28fea]

An strace narrows it down to

write(2, "(Sandbox) Caught a bad syscall a"..., 48(Sandbox) Caught a bad syscall attempt (syscall ) = 48

Child Tickets

Attachments (1)

strace.log (141.1 KB) - added by toralf 2 months ago.
strace.log

Download all attachments as: .zip

Change History (22)

comment:1 Changed 2 months ago by teor

Keywords: crash linux sandbox 040-must added
Milestone: Tor: 0.4.0.x-final
Owner: set to nickm
Points: 0.2
Status: newassigned

I think nickm understands the sandbox code the best.

comment:2 Changed 2 months ago by toralf

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

comment:3 Changed 2 months ago by pege

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.

comment:4 Changed 2 months ago by toralf

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]
Last edited 2 months ago by toralf (previous) (diff)

Changed 2 months ago by toralf

Attachment: strace.log added

strace.log

comment:5 Changed 2 months ago by firebird

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.

comment:6 Changed 2 months ago by toralf

well, indeed I upgraded it:

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

comment:7 Changed 2 months ago by pege

Cc: peter@… added
Summary: Linux kernel 5.0.3 crashes sandbox configured Tor clientSeccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4
Version: Tor: 0.4.0.2-alphaTor: unspecified

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);

Last edited 2 months ago by pege (previous) (diff)

comment:8 Changed 2 months ago by pege

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.

Last edited 2 months ago by pege (previous) (diff)

comment:9 Changed 2 months ago by nickm

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?

comment:10 Changed 2 months ago by nickm

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

comment:11 Changed 2 months ago by nickm

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?

comment:12 Changed 2 months ago by pege

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.

comment:14 Changed 2 months ago by nickm

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

comment:15 Changed 8 weeks ago by nickm

Keywords: 040-must removed

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

comment:16 Changed 7 weeks ago by pege

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.

comment:17 Changed 7 weeks ago by nickm

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

comment:18 Changed 7 weeks ago by pege

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.

Last edited 7 weeks ago by pege (previous) (diff)

comment:19 Changed 6 weeks ago by 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.

comment:20 Changed 6 weeks ago by toralf

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?

Last edited 5 weeks ago by toralf (previous) (diff)

comment:21 Changed 11 days ago by nickm

Points: 0.22-10

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.

Note: See TracTickets for help on using tickets.