Opened 13 months ago

Closed 12 months ago

Last modified 12 months ago

#28358 closed defect (fixed)

Nyx forces Tor error: sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address

Reported by: wagon Owned by:
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version: Tor: 0.3.4.9
Severity: Normal Keywords: sandbox
Cc: atagar Actual Points:
Parent ID: Points:
Reviewer: dgoulet Sponsor:

Description

If Sandbox 1 is set in torrc, Nyx (both stable 2.0.4 and git version) makes Tor write the error in log file:

[err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address [hostname redacted]! (on Tor 0.3.4.9 )

This is always written only once, during startup of Nyx.

atagar suggested me to file this ticket. He assumes that the bug is on Tor's side:

It sounds like simply calling GETINFO address causes its sandboxing code to issue a bug warning. This is either uncovering a bug on their side or this log message should be downgraded (i.e., not err runlevel or say it's a Tor bug).

Child Tickets

Change History (13)

comment:1 Changed 13 months ago by dgoulet

Keywords: sandbox added
Milestone: Tor: 0.3.4.x-final
Owner: arma deleted

Hmmm... so router_pick_published_address(get_options(), &addr, 0) which is called by GETINFO address triggers the sandbox.

Issue seems to be that sandbox_getaddrinfo_cache_disabled = 0 and sandbox_getaddrinfo_is_active = 1 which means that tor_getaddrinfo() will only query the cache and never call getaddrinfo().

Not sure here, seems the solution is either call getaddrinfo() when the sandbox is active (not entirely why we don't) or disable the getaddrinfo cache when looking up the address from the GETINFO command (using: sandbox_disable_getaddrinfo_cache()).

I'm still confused on how this can work in normal circumstances if Sandbox = 1 ONLY queries the cache?

comment:2 Changed 13 months ago by dgoulet

Keywords: regression 034-backport added
Milestone: Tor: 0.3.4.x-finalTor: 0.3.5.x-final
Status: assignednew

comment:3 Changed 13 months ago by dgoulet

Keywords: regression 034-backport removed
Milestone: Tor: 0.3.5.x-finalTor: unspecified

How getaddrinfo() behaves is actually by design with the Sandbox so yeah... GETINFO address with the current sandbox we have simply won't work.

The changes would be pretty major to make this work properly according to some discussion with nickm.

comment:4 Changed 13 months ago by wagon

dgoulet, thank you! Once it cannot be fixed in near future, should we temporarily resolve it by documenting this bug as a feature? For instance, in man torrc for Sandbox option we can say that it restricts what Tor can reply (to some commands) through its ControlPort.

comment:5 in reply to:  4 Changed 13 months ago by dgoulet

Replying to wagon:

dgoulet, thank you! Once it cannot be fixed in near future, should we temporarily resolve it by documenting this bug as a feature? For instance, in man torrc for Sandbox option we can say that it restricts what Tor can reply (to some commands) through its ControlPort.

Yes I do believe that is a good idea! You'll notice that the Sandbox option already has a series of other options that are documented to not work with it.

Adding that this particular control port command would fail is the right thing to do. Would you like to contribute this patch? :) (file to modify: doc/tor.1.txt)

Thanks!

comment:6 Changed 13 months ago by wagon

Would you like to contribute this patch? :) (file to modify: doc/tor.1.txt)

For doc/tor.1.txt from tor-0.3.5.5-alpha:

$ diff tor.1.txt-original tor.1.txt-updated
601c601
<     can not be changed while tor is running.
---
>     can not be changed while tor is running. +
603c603
<     When the Sandbox is 1, the following options can not be changed when tor
---
>     When the **Sandbox** is 1, the following options can not be changed when tor
605,613c605,614
<     Address
<     ConnLimit
<     CookieAuthFile
<     DirPortFrontPage
<     ExtORPortCookieAuthFile
<     Logs
<     ServerDNSResolvConfFile
<     Tor must remain in client or server mode (some changes to ClientOnly and
<     ORPort are not allowed).
---
>     **Address**,
>     **ConnLimit**,
>     **CookieAuthFile**,
>     **DirPortFrontPage**,
>     **ExtORPortCookieAuthFile**,
>     **Logs**,
>     **ServerDNSResolvConfFile**.
>     Tor must remain in client or server mode (some changes to **ClientOnly** and
>     **ORPort** are not allowed). Currently, if **Sandbox** is 1, **ControlPort**
>     command "GETINFO address" will not work.

I also fixed formatting problems in this option. The result was checked using the commands:

$ a2x -f manpage /path/to/tor.1.txt
$ man /path/to/tor.1

It would be good solution for now, but in future we have to make it working with Sandbox option. As I understand you, it doesn't contradict to the idea of sandbox design.

comment:7 Changed 12 months ago by teor

Milestone: Tor: unspecifiedTor: 0.4.0.x-final
Status: newneeds_review

This ticket has a patch, so it belongs in 0.4.0.

comment:8 Changed 12 months ago by dgoulet

Reviewer: dgoulet

comment:9 Changed 12 months ago by dgoulet

Status: needs_reviewmerge_ready

Took the patch in and put it in ticket28358_040_01.

(Did some modification to make it work on 0.4.0. It think it is nicely separated now, that Sandbox section was getting a bit cramped up.)

comment:10 Changed 12 months ago by nickm

Resolution: fixed
Status: merge_readyclosed

Seems fine, merged to master.

comment:11 Changed 12 months ago by wagon

Did some modification to make it work

Let me ask more. As I see it here,

When the Sandbox is 1, the following options can not be changed when tor is running:
...
ClientOnionAuthDir (and any files in it won't reload on HUP signal).

Launching new Onion Services through the control port is not supported with current syscall sandboxing implementation.

Does it mean that onionshare-like utilities will not work with sandboxed Tor? So, users have to choose to either (1) run Tor in insecure way with working secure file sharing or (2) run Tor in a secure way without file sharing at all. Sounds not good.

What are the exact restrictions on v3 onions? So, on the fly:

  1. Auth for already existing onion services (added via filesystem) cannot be added, deleted or changed through ControlPort or through files (both on client side and on server side).
  2. New onion service (server side) cannot be added by either method: through files or through Controlport.
  3. No any means to deactivate already running onion service (on server side).

Is it correct? In other words, no any change to configuration of onion service can be done on the fly (both on client side and on server side).

comment:12 in reply to:  11 ; Changed 12 months ago by teor

Replying to wagon:

Did some modification to make it work

Let me ask more. As I see it here,

When the Sandbox is 1, the following options can not be changed when tor is running:
...
ClientOnionAuthDir (and any files in it won't reload on HUP signal).

Launching new Onion Services through the control port is not supported with current syscall sandboxing implementation.

Does it mean that onionshare-like utilities will not work with sandboxed Tor? So, users have to choose to either (1) run Tor in insecure way with working secure file sharing or (2) run Tor in a secure way without file sharing at all. Sounds not good.

What are the exact restrictions on v3 onions? So, on the fly:

  1. Auth for already existing onion services (added via filesystem) cannot be added, deleted or changed through ControlPort or through files (both on client side and on server side).
  2. New onion service (server side) cannot be added by either method: through files or through Controlport.
  3. No any means to deactivate already running onion service (on server side).

Is it correct? In other words, no any change to configuration of onion service can be done on the fly (both on client side and on server side).

Maybe you can test these things on Tor, and open another ticket with the results.
Then we can change the documentation.

comment:13 in reply to:  12 Changed 12 months ago by wagon

Replying to teor:

Replying to wagon:

What are the exact restrictions on v3 onions? So, on the fly:

  1. Auth for already existing onion services (added via filesystem) cannot be added, deleted or changed through ControlPort or through files (both on client side and on server side).
  2. New onion service (server side) cannot be added by either method: through files or through Controlport.
  3. No any means to deactivate already running onion service (on server side).

Is it correct? In other words, no any change to configuration of onion service can be done on the fly (both on client side and on server side).

Maybe you can test these things on Tor, and open another ticket with the results.
Then we can change the documentation.

Maybe, but later. As I see in discussions in #28619 and #28275, even if sandbox is not used, restart of Tor is needed to be sure that everything old is deleted and no longer working. So, in strict sense, answer to "3" is yes. As concerns "1", auth cannot be deleted or changed without restart of Tor at server side. Other questions still hold.

Note: See TracTickets for help on using tickets.