debian-tor permission instructions

[saizai]

My current invocation is:

sudo -u debian-tor nyx -s /run/tor/control

Nyx should take -u debian-tor as both a CLI & nyxrc option, and drop privs to minimum necessary so it's not running escalated.

Alternatively, the man page should give instructions on e.g. what chgrp to set on the socket (or torrc config lines, or whatever) so that it can run as the current user w/out sudo.

[atagar]

Thanks Sai. Tor's debian permissions have long been a pain point. We discussed this back in March but I forgot to make a ticket, so hijacking this one.

When tor is running as debian-tor we should advise our users to run sudo adduser $USER debian-tor and log back in. I'll add that message at some point if nobody gets to it before me.

[saizai]

I still suggest having a CLI & config flag for this. Better still, check the socket's ownership / ACL at launch and use that by default unless the current user has group access or the like.

In general I think it's always best to do the right thing by default if possible and not make the user have to remember (let alone respecify on each invocation) something like tor's run-as user. Especially since this is an issue that is likely to cause either failure or security issues, eg if run as an ordinary user or as root.

[saizai]

(I'm not certain whether adding current user to the debian-tor group is a correct solution. I don't have any clear objection; it just twigs my "this might have undesirable side effects" sense. I defer to your judgment but request you give it more thought first.)

[atagar]

In general I think it's always best to do the right thing by default if possible

Hi Sai. Agreed, working out of the box is ideal. However, tor's restricted control socket force users to grant themselves access in one fashion or another (sudo, chmod, adduser, etc).

Brainstorming, I suppose sudo apt-get install nyx could leverage its root permissions to do something of the form if there's a debian-tor permission group do X. However, we lack a good X. Our deb doesn't know which users will run Nyx, and by extension require socket access.

While I'd love for Nyx to work out of the box, overbroad control port access is a security threat so sadly some amount of setup will likely always be required.

I'm not certain whether adding current user to the debian-tor group is a correct solution. I don't have any clear objection; it just twigs my "this might have undesirable side effects" sense. I defer to your judgment but request you give it more thought first.

Actually, this suggestion came from Roger (tor's co-author). Every solution I've heard has some disadvantage (adduser's being that it requires logging back in). If anyone has something better I'm all ears!

[armadev]

Right -- one of the features of the adduser approach is that you do it once, for whichever user will be running nyx, and then you don't need to mess with it after that: nyx has the permissions to reach the control socket, it does so, it doesn't receive permissions it doesn't need, etc.

The reason adding your user to the debian-tor group is ok is because the control socket etc are reachable by the group, but Tor's keys and other sensitive things are only reachable by the debian-tor user (not the group). So it is intended to be a good balance between all these conflicting goals.

I think Damian is right that the deb isn't really in a good position to add your user to the right group, because it doesn't know who will be running nyx.

Oh, and as a last thought, saizai makes a good point that changing things once and then having them just work after that is best, and that's what this suggestion does, but we might be wise to tell the user that's how it works too. Like, with an extra sentence when we give the instructions, explaining you only need to do these steps once, and then they'll be in place for future nyx runs.

[saizai]

What if nyx were to set itself (& the local user's config file) as chown'd by the same user & group as the tor socket, but with the usable-by-others flag set?

(I'm blanking on the correct name for this. It's usually for stuff that has to run as root, eg because it creates sockets or the like, but is sufficiently locked down to expose to regular users. -s IIRC?)

While at it, what about having nyx provide an option to dump its own config file based on current settings, like it does for updating torrc?

[saizai]

Actually I guess that last raises a more basic first question: what is the security level of nyx?

I could see arguments for any of these (going from top of my head, so not guaranteeing this is a thorough security analysis):

1. root, ie sudo access.

• Nyx can change torrc, and see sensitive traffic from other users, which is a root-ish thing to do.

2. debian-tor user, ie sudo -u debian-tor access.

• Really those are things that tor itself can do without root.

3. debian-tor group, ie useradd $USER debian-tor / group access.

• Mostly these are things that only require access to the control socket, and to read the torrc. The torrc write functionality is (or could be) limited to equivalent to what can be done by the control socket, though "make it permanent" is an escalation from "do it for now".

4. all users with access to the SOCKS socket/port, ie not in debian-tor anything.

• Nyx mostly does, and certainly could more so, expose only a limited subset of control socket functionality, like top exposes only a subset of root's process monitoring & control powers. So eg it could run most of the monitoring functionality for anyone, but prevent the following to only work if invoked at a higher run level (eg # 2/3 above)
  a. the last pane (which IIRC is an arbitrary low level REPL for the control socket; I've not actually used it)
  b. live config changes
  c. torrc update
  d. tor service HUP or reload
  e. (?) new identity (not sure if this affects other users)
  f. (?) access to sensitive data like unscrubbed addresses, node connection log, …? (depends on the access levels of the relevant log files I guess, or developer judgment of which things in the log pane filter options are more sensitive, eg risk of disclosing other users' privacy)
  g. (?) access to detailed traffic data of other users, as opposed to that which is only about the current user or which is sufficiently generic about others' (I'm not sure how much this is possible — don't know tor well enough to suss out socket isolation vs side channel attacks vs shared-but-harmless data vs "can be anonymized enough to not really matter" data)

My rough feeling is that a security model like that of top, where functionality depends on invocation privileges, would be better than an all or nothing model like it has now.

This should (AFAICT) mostly allow the simple expedient of an ACL which is essentially "check if $currentuser can do $x the normal way, except for a very restricted subset for which we're allowing privilege escalation to everyone".

Nyx mostly is very much like top or iftop, in that the 99% use case is just to watch what's going on with one's own usage, and it just happens that the implementation requires this to go over a control socket with much broader powers.

So it could do the same privilege model:

1. If any random user with SOCKS access only invokes nyx, give them detailed info on their own traffic, control of stuff that only affects themselves (& is within their ~privilege limits as determined by torrc), and generalized info about everything else (like total traffic).
2. If a user with group but not user access to the tor control socket invokes nyx, give them full info access but not write access to settings & not the full socket REPL.
3. If a user with user access to the control socket (or root) invokes nyx, give them access to everything.

This approach would turn the question of "can you run nyx at all" into "what privilege level do you have", which seems to me like a more natural / unix-spirit way of doing it, and one that allows the majority use case without requiring (or recommending) that the user have higher privileges than they need.

This also benefits even users who do have access to that access (sudoers). They can run it in unprivileged mode most of the time, and be required to escalate if they want to do riskier stuff — just like eg if you run htop, you rarely need to do stuff like nice -$x, kill $otheruserprocess, lsof, etc, and you can't accidentally do those in a normal invocation; you can if you want, but have to sudo htop to do so. This serves as a good reminder of when one is using superpowers, and follows the good general mitigation principle of "always run at the lowest privilege you can".

Thoughts?

Comments on how that actually does break down into privilege levels for nyx/tor? (I'm not nearly expert enough to have confidence here — neither on the basic questions like "what access is needed to do what", nor "what seemingly innocent thing might be an unacceptable risk side channel against other users on the same system".)

PS I know Roger. Lovely guy. Been too long since I've seen him. 😕

[atagar]

This approach would turn the question of "can you run nyx at all" into "what privilege level do you have"... Thoughts?

Hi Sai. Honestly this got a bit long for me and I think we already provide what you describe. Nyx provides what functionality it can, falls back if able, and informs the user with an error as a last resort.

all users with access to the SOCKS socket/port, ie not in debian-tor anything

I suspect there's a misunderstanding. Tor's control socket can only be read by the debian-tor user or group. That is why you must run as that user (sudo -u debian-tor) or add yourself to its group (sudo adduser $USER debian-tor). Without debian-tor permissions nyx cannot read the socket, and by extension do anything at all.

[armadev]

I read saizai's comments as providing two suggestions: (1) what if we set nyx to be setgid debian-tor, so it automatically gets to access tor's control socket, and then there's no need for the human to muck with things? and (2) what if we redesigned tor's control protocol so there's a clear separation between "read-only general knowledge that's safe for any process to learn" and "read-write you can only do these things if you have the right permissions"?

For suggestion 1, that seems equivalent to just opening up the tor control socket to any user, since any user would be able to interact with it via nyx. And that seems unwise, since part of the point of separating things by user is so that e.g. your 'nobody' user can run your scary service but if it gets broken into, it can't do much else (at least not without a local exploit too).

And for suggestion 2, I think that is a fine idea in theory but in practice it gets complicated quickly, since many control port interactions seem harmless at first but then have more subtle anonymity or privacy implications on further thought. So I expect the set of the control protocol that would be "safe for any user" would end up being very small indeed.

For that second idea, a bunch of projects have tried to write a "tor controller sandbox" that proxies requests to Tor but only a few safe ones. Maybe some of them have made useful progress? But last I checked (which was a while ago), I wasn't excited at the idea.