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

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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: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...
 >

 No, I think you're confused. I am suggesting build time compilation; users
 don't run setup.py, they install the deb which has everything all setup -
 this is totally standard for C programs that need to be compiled. In
 general, a user installs a C program that is compiled and available as a
 binary package. I am suggesting that arm should compile the setuid wrapper
 at build time (deb build time, src unpack/whatever package build time,
 etc).

 > 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.

 The implementation is off by default for every user except those that are
 already root. You must explicitly be a part of the "tor-arm" group to even
 execute the C wrapper _at all_ and it will not work on Windows.

 I think this is reasonably safe and it at least does a sanity check on the
 config, backs up the old config and *it does not restart Tor* - the
 program is a merely a wrapper that allows automatic authorization with a
 VERY small attack surface. Thus, if a user is not already root or the user
 is not in "tor-arm" - they are not even able to execute the program - they
 will get a permission denied error from the OS.

 > It's a pity the setuid bit is specifically disabled on most systems for
 shell scripts. I'd find that much less objectionable.
 >

 I think this is very confusing. When you execute a shell script, you're
 actually executing the interpreter specified in the #! line. Thus, it is
 not the shell scrip that is set uid ,it's the interpreter. You'd have to
 be nuts to setuid python or bash and so the wrapper is a solution that
 allows a single script but not all of python or bash to be setuid. I have
 coded it in a very defensive manner and I have even made sure that by
 default, no user may even execute the binary. It may not be perfect and
 I'm open to criticisms of ways this may break.

 > 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.
 >

 I understand your viewpoint. I don't even entirely disagree. I do however
 feel like "hand edited" is exactly what we're enabling here. It is also
 automatically making a backup and verifying that Tor would consider it a
 valid configuration file.

 I tried to suggest the simple option of something like the
 /etc/default/tor Vidalia hack but weasel was against it. I understand his
 reasons and I wrote this wrapper such that a user who wants to use arm may
 configure Tor and it's *arm* that does the work. This releases weasel or
 anyone else from having to deal with this crazy shit but also allows us to
 actually move forward. It means that arm can now take over Tor in a safe
 way that persists, even if Tor starts as root from an init.d script. This
 is the default and it solves a major problem that users have when Vidalia
 takes over Tor; that is - if they don't login to the system, Tor never
 starts. We will not have that problem - an important problem to solve on a
 headless machine!

 > - 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.
 >

 That means you need to make arm a daemon and it will never be able to bind
 to privileged ports unless arm spawns Tor as root. I think that's a HUGE
 attack surface and arm was not designed for this task.

 > - 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.

 Nick has nothing to do with this other than me asking for a sanity check
 on the general idea. There is no end user compilation.

 >
 > 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?
 >


 > -Damian
 >
 > PS. No offense at all intended toward your work, Jake. I'm just finding
 that the more I think about this change the more I'm uncomfortable with
 it.

 I think it's annoying that we can't easily make the Tor package support
 arm as we did with Vidalia. I also however think that weasel is correct in
 that our dirty hack for Vidalia was the wrong thing then and it would be
 wrong to add another one for arm. So I'm torn but I have written a
 solution. I believe it's safe and meets all the other weird requirements
 that we've stumbled over for a while.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3629#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs