[tor-bugs] #3629 [arm]: Arm/Tor Deb Torrc Configuration

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Fri Jul 22 23:01:03 UTC 2011


#3629: Arm/Tor Deb Torrc Configuration
-------------------------+--------------------------------------------------
 Reporter:  atagar       |          Owner:  ioerror
     Type:  enhancement  |         Status:  new    
 Priority:  normal       |      Milestone:         
Component:  arm          |        Version:         
 Keywords:               |         Parent:         
   Points:               |   Actualpoints:         
-------------------------+--------------------------------------------------

Comment(by ioerror):

 Replying to [comment:3 Sebastian]:
 > Replying to [comment:2 atagar]:
 > > > I was hoping that you would adopt this helper as a thing arm
 installs on more than just Debian.
 > >
 > > Woah, that changes this. Just to make sure I'm understanding this
 right, you want arm's install script to automatically execute gcc on the
 user's system? If so then this is the first I've ever heard of an
 installer doing compilation on an end user system...
 >
 > install-time compilation doesn't make sense. But I don't think this is
 what was proposed here? I took it as build-time compilation, which is
 standard
 >

 Correct. I'm suggesting the standard C program compilation/build process
 that we use for any program. This really doesn't change very much, if the
 deps for the C program around available, we should just install the Python
 app as normal. The trick here is simply to add the build-deps/deps to the
 debian/control file for a basic C program and ensure that there is
 something to call the Makefile.

 > > If this was just for Debian then I'd be happy to go with pretty much
 any hack you and Peter wanted, but if this is for arm in general then I'm
 much more concerned. It's a pity the setuid bit is specifically disabled
 on most systems for shell scripts. I'd find that much less objectionable.
 >
 > suid root scripts are generally a sad thing from experience
 >

 You cannot mark a script suid, only the interpreter or a dirty hack that
 does something similar to what I've done.

 > > My feeling is this:
 > > - If Tor decides to have root permissions on its torrc then Tor is
 clearly indicating that they want it to only be hand edited. Personally I
 think this is dumb since it breaks SAVECONF and hurts users, but oh well.
 Controllers (both arm and Vidalia) should treat this torrc as being kinda
 useless and work around it.
 >
 > Tor doesn't decide this. It is whoever is packaging Tor that makes the
 decision. Personally I think it is a great idea, I find it horrible that
 some kind of networking daemon with the power of Tor should have the power
 to change its own configuration. This is, as far as I know, only
 implemented as a hack so that controllers on remote systems can work and
 change the configuration persistently.
 >

 Right. Weasel did not want us to make a bunch of dirty hacks to the Tor
 package and I wrote this patch as a way to solve the problem in arm; it's
 useful for many cases where arm controls a Tor but does not *start* the
 Tor. This happens all the time and in fact, by default, arm could just
 dump the current Tor config file, add a control port/auth config stanza,
 and then overwrite /etc/tor/torrc - so in a sense, we can use this to
 easily take over Tor but only when the sysadmin is OK with said takeover.
 In any case, we need something that does this specific task without user
 intervention in the shell. If my implementation is sound, I'd like to
 think this specific solution is safer than a generic solution that depends
 on a lot of external stuff.

 > > - When I scripted arm's setup wizard I took the same tactic as
 Vidalia, making a torrc in my own data directory for an arm managed Tor
 instance. If fixing the permissions on the system torrc and editing the
 init.d script are both forbidden then the only real option left to
 controllers is to ignore those and make their own.
 >
 > I feel like this is a good approach for a TBB-like client instance. I'd
 never want to run a relay like that, just for port opening reasons and
 resource consumption etc.
 >

 Right. That's exactly why I didn't suggest we write /etc/init.d/arm as the
 solution. Arm was not designed to run as root and it seems like while it
 might happen, it's a lot lot lot more work to go down that path.

 > > - This setuid hack is in effect the same as a chown on the system
 torrc. That in itself I'm fine with (assuming Nick was on board). However,
 this is introducing an extremely ugly song-and-dance for working around
 Tor's permission issue and, in my opinion, end user compilation pushes the
 hack way too far. If we think that this hack is ok then we should just
 skip the overly complicated workaround and issue what's in effect a chown
 directly.
 >
 > I think nick doesn't have anything to do with it - it's a packaging
 decision. (I don't mean nick won't have a useful opinion here, just that
 this is not something that Tor decided to do a certain way).
 >

 Correct. Nick said I should ask an old unix beard, I generally agree and
 will seek out such a sage for my next code review.

 > > All this said, if others in the community really think that this is
 the best route forward then I'll bite the bullet in the name of
 interoperability. Sebastian, Nick: what are your opinions?
 >
 > I think the only sane way forward is to prompt for root when a root-
 owned file is supposed to be overwritten

 This view point helps me to understand why Linux is such a pain in the ass
 to use. :) We do lots of stuff every moment where this isn't happening -
 udev, NetworkManger, etc comes to mind.

 The user friendly way is that you have a user that is allowed to use arm
 to perform a task. In this case, we're reconfigure Tor. They might mess up
 Tor or the system in the process. So we limit what they can do to a few
 things and we trust that without a lot of mucking around, they won't break
 it on accident from arm.

 However, at some point, they might tamper with the contents of the file,
 regardless of what arm does with the contents. This problem is basically
 universal. The user can always break Tor if they are allowed to
 reconfigure it. However, we try to drop privs and verify that Tor would be
 happy. If it's happy, we're basically at a dead end - we can't really
 perform too many more tests - I guess we could ensure it's a small size or
 something similar. I'm open to making it really limited, I currently
 limited it to 1024*1024 just to be semi-defensive (thanks radii!).

 Still this doesn't mean the config is *correct* - it merely means that
 it's *valid* as far as arm and Tor are concerned. In theory, if the config
 will crash, it will first crash as nobody, so it should be at worst, a uid
 switch from $user:tor-arm to nobody:nogroup. That seems pretty safe.

 We do everything we can to help them out and to stop them from really
 screwing up the system on accident. arm will only write a valid config,
 we'll verify it in the python script called by the wrapper, we'll only
 overwrite the system config *after we backup the original config* with the
 config we verified and the only user that can even start it is one we
 explicitly added to a group that we created at install time.

 If we gave them sudo or something else, they'd have a similar set of
 problems to solve with a much larger attack surface and with a bunch of
 moving parts we don't control.

 In any case, we'd need to get some kind of interaction which seems nearly
 impossible on a headless system unless we don't prompt for passwords. I
 guess we'd have to solve that with a similar user or group trick and then
 we'd have a giant attack surface, a different program to configure and so
 on.

 But I'm writing too much; I hope this clears everything up. Now perhaps
 someone can break my one trick pony and then I'll try again. :)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3629#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list