[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3629 [arm]: Arm/Tor Deb Torrc Configuration
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs