Opened 10 months ago

Last modified 5 weeks ago

#28356 assigned defect

DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash

Reported by: wagon Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.4.9
Severity: Normal Keywords: tor-crash, regression, 040-roadmap-proposed, 035-backport, 029-backport-maybe, 035-can, postfreeze-ok, 040-deferred-20190220, 033-unreached-backport-maybe
Cc: atagar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Problem 1

By default DataDirectory and CacheDirectory is the same. On Debian it is /var/lib/tor. If you set DataDirectoryGroupReadable 1 in torrc (and forget about CacheDirectoryGroupReadable) and then restart Tor, you expect granting permissions to this directory. However, Tor will not do that, but change drwx--S--- permission to drwx------ for this directory (which is itself not logical---removing permissions instead of granting them). Tor will also issue a warning:

[warn] Fixing permissions on directory /var/lib/tor

Later this warning will be repeated at each startup of Tor. I think that this warning should be improved, e.g.:

[warn or err] DataDirectoryGroupReadable and CacheDirectoryGroupReadable links to the same directory. You have to set both of them to 1 of both of them to 0.

Maybe you have another suggestion (e.g., if any of these options is 1, another is 1 too). man torrc doesn't tell anything about this conflict. It should be addressed in man page too.

Problem 2

The situation is worse when your torrc has Sandbox enabled:

DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1
Sandbox 1

In this case Tor successfully starts, but if you issue SIGNAL RELOAD command (e.g., using tor-prompt), Tor immediately crashes with the log:

============================================================ T= XXXXXXXXXX
(Sandbox) Caught a bad syscall attempt (syscall chmod)
/usr/bin/tor(+0x1a4d66)[0x556326474d66]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/usr/bin/tor(+0xfafed)[0x5563263cafed]
/usr/bin/tor(set_options+0x2ed)[0x5563263d42dd]
/usr/bin/tor(options_init_from_string+0x4c7)[0x5563263d6d97]
/usr/bin/tor(options_init_from_torrc+0x471)[0x5563263d72f1]
/usr/bin/tor(+0x55531)[0x556326325531]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xe35)[0x7f63ca776a15]
/usr/bin/tor(do_main_loop+0x25f)[0x556326325e3f]
/usr/bin/tor(tor_run_main+0x1165)[0x556326328315]
/usr/bin/tor(tor_main+0x3a)[0x55632632032a]
/usr/bin/tor(main+0x19)[0x556326320099]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f63c90fab45]
/usr/bin/tor(+0x500e9)[0x5563263200e9]

Should Sandbox be in conflict with these option? If yes, this should be documented in man page, and Tor has to complain an error during startup.

Problem 3

Suppose, you disable Sandbox, but keep the options DataDirectoryGroupReadable and CacheDirectoryGroupReadable in place. During start Tor sets directory permissions to drwxr-x--- allowing debian-tor group to list files.

If you later grant read access to any file in this directory, Tor will remove this access soon. E.g., state file loses its group read permission at each Tor's startup. Other files may lose it less frequently. We are trapped in the situation where DataDirectoryGroupReadable and CacheDirectoryGroupReadable are useless: what's the goal to be able to read directory's content, bit be unable to read any file inside it?

Earlier it was in less conflict with different tools which control Tor, because it was recommended to run each tool on behalf of debian-tor user. Now it is recommended to run it from another user who is a member of debian-tor group (see discussion in #25890), but "group approach" also fails...

Child Tickets

Change History (16)

comment:1 Changed 10 months ago by teor

Keywords: tor-crash regression 035-roadmap-proposed 035-backport 034-backport 033-backport-maybe 029-backport-maybe added
Milestone: Tor: 0.3.5.x-final
Priority: MediumHigh

Thanks for this bug report. Unexpected crashes are bad. We'll get on to fixing this.

comment:2 Changed 10 months ago by wagon

Problem 4

We have similar problem with Tor logs. Default permissions are:

# ls -la /var/log/tor | awk '{print $1,$3,$4,$5,$9}' | column -t
total
drwxr-s---  debian-tor  adm   4096  ./
drwxr-xr-x  root        root  4096  ../
-rw-r--r--  debian-tor  adm   0     log

Since the default group is not debian-tor, user in debian-tor group (e.g., user which uses Nyx) cannot list a content of log file. By default, Nyx wants to print its content. So, now, if we want Tor logs shown in Nyx, we have either to change the group manually (which is not good) or run Nyx under debian-tor user (which is not recommended too).

comment:3 Changed 10 months ago by wagon

Does /run/tor has more privileges than necessary? Defaults:

# ll /run/tor | awk '{print $1,$3,$4,$5,$9}' | column -t
total
drwxr-sr-x  debian-tor  debian-tor  120  ./
drwxr-xr-x  root        root        420  ../
srw-rw----  debian-tor  debian-tor  0    control=
-rw-r-----  debian-tor  debian-tor  32   control.authcookie
srw-rw-rw-  debian-tor  debian-tor  0    socks=
-rw-r--r--  debian-tor  debian-tor  6    tor.pid

Many system services successfully run with chmod o-rwx /run/name_of_service. Is there any reason why any user on the system should be able to read the content of /run/tor directory and tor.pid file, socks, etc? Any user who needs it, should be either root or be in debian-tor group. Do I miss something?

comment:4 Changed 10 months ago by nickm

Keywords: 035-can added

comment:5 Changed 9 months ago by wagon

what's the goal to be able to read directory's content, bit be unable to read any file inside it?

I'll quote atagar:

any direct use of tor's data directory is a bad idea

Do we have anything useful that can be obtained only from Tor data directory directly, i.e. cannot be learnt from ControlPort? Some historical data about guard use written in state file?

comment:6 Changed 8 months ago by wagon

Should milestone be changed to 0.4.0.x? 0.3.5.x is already in rc state.

comment:7 Changed 8 months ago by nickm

Keywords: 040-roadmap-proposed added; 035-roadmap-proposed removed
Milestone: Tor: 0.3.5.x-finalTor: 0.4.0.x-final

comment:8 Changed 8 months ago by nickm

Keywords: postfreeze-ok added

Mark some tickets as postfreeze-ok, to indicate that I think they are okay to accept in 0.4.0 post-freeze. Does not indicate that they are all necessary to do postfreeze.

comment:9 Changed 7 months ago by gaba

Owner: arma deleted

comment:10 Changed 7 months ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

comment:11 Changed 7 months ago by teor

These open, non-merge_ready tickets can not get backported to 0.3.3, because 0.3.3 is now unsupported.

comment:12 Changed 7 months ago by teor

Keywords: 033-backport-unreached added

Hmm, I guess they should still get 033-backport-unreached

comment:13 Changed 3 months ago by nickm

Keywords: 034-backport removed

Removing 034-backport from all open tickets: 034 has reached EOL.

comment:14 Changed 5 weeks ago by teor

Keywords: 033-unreached-backport added; 033-backport-unreached removed

Fix 033-unreached-backport spelling.

comment:15 Changed 5 weeks ago by teor

Keywords: 033-unreached-backport-maybe added; 033-backport-maybe removed

Remove outdated 033-backport-maybe

comment:16 Changed 5 weeks ago by teor

Keywords: 033-unreached-backport removed
Note: See TracTickets for help on using tickets.