Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

changed milestone to %Tor: 0.3.5.x-final

added 035-backport 041-backport 042-backport BugSmashFund actualpoints::0.3 component::core tor/tor consider-backport-after-0431 crash linux milestone::Tor: 0.3.5.x-final owner::nickm priority::medium resolution::fixed reviewer::nickm sandbox severity::normal status::closed type::defect version::tor 0.2.5.1-alpha labels

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

Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

Child items 0

Activity