Opened 2 years ago

Last modified 8 months ago

#26580 new defect

torsocks complains about unknown system call #417 on FreeBSD

Reported by: yurivict271 Owned by:
Priority: Medium Milestone:
Component: Core Tor/Torsocks Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:



torify telnet {some-onion}.onion {some port}

When it connects, pressing Ctrl-C prints this error:

^C1530319165 WARNING torsocks[69407]: [syscall] Unsupported syscall number 417. Denying the call (in tsocks_syscall() at syscall.c:496)

and telnet doesn't exit.

torsocks-2.2.0 on FreeBSD 11.1

Child Tickets

Change History (5)

comment:1 Changed 2 years ago by nickm

Component: - Select a componentCore Tor/Torsocks
Owner: set to dgoulet

comment:2 Changed 2 years ago by yurivict271

All unknown system calls should be passed, because they have nothing to do with socket operations. This would be a correct fix of this.

comment:3 in reply to:  2 Changed 20 months ago by onirony

Replying to yurivict271:

All unknown system calls should be passed, because they have nothing to do with socket operations. This would be a correct fix of this.

Agreed, I think that everyone would prefer that. There are currently two (very solvable) problems.

1. Every Unix-like OS has it's own syscall sandboxing system.

Right now Torsocks is whitelisting a small subset of syscalls (bad). Modern operating systems provide mechanisms to implement syscall blacklists (good) instead. However, everyone does it differently. Viz,

Linux: seccomp
FreeBSD: capsicum
OpenBSD: pledge
OS X: App Sandbox (which deprecates sandbox_init()).

Redesigning Torsocks to take advantage of these tools would require significant reengineering, but is probably the best/only approach. At the very least, we could start with Linux/seccomp, which covers the overwhelming majority of Torsocks' userbase, then move on to FreeBSD/Capsicum, then MacOS/App Sandbox, and eventually OpenBSD/pledge. However, there is still the issue of...

2. Kernels regularly add new networking syscalls.

We are unlikely to keep totally up to date with every new syscall added to Linux, MacOS, OpenBSD, et al. This puts users in risk when they run an application through torsocks assuming their traffic is being routed through Tor, only to have their IP leaked because their application made a networking-related syscall we didn't know about.

MacOS, for example, has connectx. If Torsocks had relied on a blacklist at the time that connectx was released, all of the torified applications using connectx would have had their IP addresses exposed. Instead, Torsocks merely failed.

So there are definitely some downsides, but compared to the alternative (manually adding every non-socket syscall from every popular *nix system) definitely appeals to me.

comment:4 Changed 16 months ago by gaba

Owner: dgoulet deleted
Status: newassigned

removing dgoulet from ownership in torsocks component

comment:5 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.