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
Component: | - Select a component → Tor |
---|
comment:3 Changed 5 years ago by
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 Changed 5 years ago by
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 Changed 5 years ago by
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
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.
comment:7 Changed 5 years ago by
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
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.
comment:9 Changed 5 years ago by
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
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
Makes sense. In my opinion, the policy should be "do it like the deb does it."
comment:12 Changed 5 years ago by
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
Milestone: | → Tor: 0.2.8.x-final |
---|
comment:14 Changed 4 years ago by
Points: | → small/medium |
---|---|
Priority: | normal → minor |
comment:15 Changed 4 years ago by
Milestone: | Tor: 0.2.8.x-final → Tor: 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:17 Changed 3 years ago by
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
Keywords: | tor-03-unspecified-201612 removed |
---|
Remove an old triaging keyword.
comment:19 Changed 2 years ago by
Keywords: | tor-client log permissions umask added |
---|---|
Severity: | → Normal |
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.