Opened 5 years ago

Last modified 2 years ago

#16070 new defect

Tor log doesn't have to be world readable

Reported by: yurivict271 Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client log permissions umask
Cc: Actual Points:
Parent ID: Points: small/medium
Reviewer: Sponsor:

Description

Currently log is:

-rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log

tor-0.2.6.7

Child Tickets

Change History (19)

comment:1 Changed 5 years ago by atagar

Component: - Select a componentTor

Fixing the component. Personally I think if this is done at all it should be a new torrc option, similar to CookieAuthFileGroupReadable. Dropping global readability will break log prepopulaton for nyx.

comment:2 Changed 5 years ago by yurivict271

Shouldn't nyx run as _tor too?

comment:3 Changed 5 years ago by atagar

Nope. In the past I've given that advice since on some platforms it avoids permission gotchas but in general it's discouraged.

comment:4 in reply to:  description Changed 5 years ago by arma

Replying to yurivict271:

Currently log is:

-rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log

tor-0.2.6.7

It indeed doesn't have to be, but I think it's fine for it to be.

Put it in a directory that the world can't reach, if you want the world to not reach it. That's how the deb does it for example:

$ ls -ld /var/log/tor
drwxr-s--- 2 debian-tor adm 4096 May 13 07:42 /var/log/tor

comment:5 in reply to:  2 Changed 5 years ago by arma

Replying to yurivict271:

Shouldn't nyx run as _tor too?

See #10702 for why this is bad and a recommended alternative.

comment:6 Changed 5 years ago by yurivict271

These are some recommended practices and reasoning.

But is there the documentation on how the third party apps should access tor for administration purposes? The above bug report says that group debian-tor is required. Is this formally described anywhere that the other, distinct group is required, which files should have which groups? Without such documentation other distros will improvise and do whatever they feel they need to fill in the blanks. (even under Debian brand, many, like Mint for ex., build their own modified packages.)

On FreeBSD, for ex., arm package doesn't create any other group. I don't know what does it do for access. Probably only works as root.

I think tor should supply the script that will set required permissions for the third party access, setting the group where needed.

Last edited 5 years ago by yurivict271 (previous) (diff)

comment:7 Changed 5 years ago by atagar

But is there the documentation on how the third party apps should access tor for administration purposes?

Generally third party apps (tor browser, vidalia, nyx, etc) would only interact with Tor via its control port.

This isn't always practical. Nyx (aka arm), for instance, reads the log file and retrieves information from /proc. But if tor provides that information via the control port then that'll be the clearly right method of getting it.

Nyx generally doesn't have trouble getting the information I need since the log file and /proc are world readable. I'm not sure why you think Nyx only works as root - it shouldn't.

comment:8 Changed 5 years ago by yurivict271

Nyx generally doesn't have trouble getting the information I need since the log file and /proc are world readable.

But nothing should really be world readable. Also to connect to ctrl port process needs permissions:

srw------- 1 _tor _tor 0 May 17 15:12 ctrl

So if I run nyx with some regular user, it will fail. There should be the policy and documentation on which users can connect, and what groups and permissions are needed.

Also /proc is the linux artifact, not a good idea to use it and rely on it in general. Such info should be accessed through some generic interface.

Version 0, edited 5 years ago by yurivict271 (next)

comment:9 Changed 5 years ago by arma

These are all packaging things, not Tor things.

Tor shouldn't prevent packagers from doing reasonable things. After that it's up to the packagers.

comment:10 Changed 5 years ago by yurivict271

If tor sets the right policy, it will be likely followed by most. If tor doesn't, half of packagers will do random things. There will generally be more security problems. Many just don't understand security to do this right.

comment:11 Changed 5 years ago by arma

Makes sense. In my opinion, the policy should be "do it like the deb does it."

comment:12 Changed 5 years ago by atagar

But nothing should really be world readable.

*shrug*. If that's your view then you're welcome to impose whatever you'd like on your system. When it comes to defaults that policy is debatable.

So if I run nyx with some regular user, it will fail. There should be the policy and documentation on which users can connect, and what groups and permissions are needed.

Ah, so you're using a ControlSocket rather than a ControlPort, and restricting it to just the tor user? If that's how your platform is set up then indeed, guess someone painted you into a corner so third party apps gotta run as the tor user.

Also /proc is the linux artifact, not a good idea to use it and rely on it in general.

Yes, it's a linux artifact. To get resource usage and connection information Nyx uses /proc if it's available (since it's the most performant), then falls back to shelling out to things like lsof, netstat, and friends. If none of that works then the user simply doesn't get the information we were trying to retrieve.

comment:13 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:14 Changed 4 years ago by nickm

Points: small/medium
Priority: normalminor

comment:15 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

Move a bunch of (but not all) low-priority items to 0.2.???. If you write a patch, it can still get into 0.2.8

comment:16 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:17 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:18 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:19 Changed 2 years ago by nickm

Keywords: tor-client log permissions umask added
Severity: Normal
Note: See TracTickets for help on using tickets.