Opened 6 years ago

Closed 4 years ago

#10702 closed defect (fixed)

arm tells users to "sudo -u debian-tor arm", which lets arm read tor's keys

Reported by: arma Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/Nyx Version:
Severity: Keywords:
Cc: kostas@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

in config/strings.cfg:

msg.setup.arm_is_running_as_root Arm is currently running with root permissions. This isn't a good idea, nor should it be necessary. Try starting arm with "sudo -u {tor_user} arm" instead.

Telling the user to run arm as the tor user exposes all of /var/lib/tor/ to arm, which is probably more than needed and likely more than expected.

At least on debian, the right answer is "sudo adduser $USER debian-tor" and then run arm as the normal user (after logout/login as needed). See #10700 for where this topic came up.

Child Tickets

Change History (8)

comment:1 Changed 6 years ago by arma

Summary: arm tells users to "sudo -s debian-tor arm", which lets arm read tor's keysarm tells users to "sudo -u debian-tor arm", which lets arm read tor's keys

comment:2 Changed 6 years ago by wfn

Cc: kostas@… added

comment:3 Changed 5 years ago by alphawolf

The permissions on /var/lib/tor and /var/log/tor will need to be adjusted in order for "sudo adduser $USER debian-tor" to work 100%. Arm wants to read the state file to prepopulate bandwidth information, but the debian-tor group does not have read permission on /var/lib/tor/state. Arm also wants to read tor's log file, but the default group for /var/lib/tor is 'adm'.

Can we get the default install to `chmod g+x /var/lib/tor` and `chmod g+r /var/lib/tor/state`?  Leave ./keys without group read/execute permission of course.

Not sure what to do about the logs... suggest users "sudo adduser $USER adm" ?

*(Permissions based on a default 0.2.4 install from deb.torproject.org on Debian Jessie)

comment:4 Changed 5 years ago by arma

No, I think those are bad steps rather than good ones.

If Tor wants to export more data to its controllers, it should do it in a controlled fashion via the control protocol. It shouldn't just open up more file-system permissions.

(More generally, I think arm should ask Tor questions via the control protocol more, rather than bypassing Tor and trying to use the local system to discover Tor things itself.)

comment:5 Changed 5 years ago by atagar

(More generally, I think arm should ask Tor questions via the control protocol more, rather than bypassing Tor and trying to use the local system to discover Tor things itself.)

In an ideal world yes, it would be nice if Tor provided controllers with this and other information. But it doesn't. Years ago you asked me to write proposals for things arm would like and I sunk quite a bit of time into that. Trouble is that proposals don't magically turn into code. Without somebody implementing these in Tor itself this is not really realistic. :)

comment:6 Changed 5 years ago by arma

Where are these proposals?

comment:7 Changed 5 years ago by atagar

... though not sure how relevant they still are (I wrote those back in 2010). Looks like it includes state information, which arm presently retrieves from the DataDir.

comment:8 Changed 4 years ago by atagar

Resolution: fixed
Status: newclosed

Probably about time I cleaned up old nyx tickets. :P

Changed, if this causes troubles for anyone then we'll give more per-platform advice. We might need to advise this on certain platforms, but agreed in general it should be discouraged.

Note: See TracTickets for help on using tickets.