Opened 14 years ago

Last modified 7 years ago

#254 closed defect (Implemented)

tor service runs with to much privileges

Reported by: cakruege Owned by: phobos
Priority: High Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: cakruege, arma, JLP Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The tor service installed via "tor -install" has to much rights.
It runs as user "local system" (equivalent to root under *nix) but it can be changed "local service" without any problems.

I've posted the problem on "or-talk@…" with this subject
"bad security setting for win32 tor service" on 19. August 2005 and their is a patch from "Matt Edman" as a reply, but
the problem exists until now.

Please fix it.

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

Child Tickets

Change History (19)

comment:1 Changed 14 years ago by arma

http://archives.seul.org/or/talk/Aug-2005/msg00176.html lists a potential problem with
moving it to 'local service', so step one is to convince Nick that he's wrong.

Another option is to help patch the whatever-should-be-patched to create a separate Tor
user for services. This seems like the smarter approach all-around.

Alas, the Tor developers aren't Windows people, so we have to guess the best we can based
on listening to what everybody says. I agree that it's sub-optimal currently.

comment:2 Changed 14 years ago by cakruege

a) what is worse?
root compromise through TOR or stealing TORs private keys through other buggy service?
b) it's not a problem to create a new user account and run tor with this account:
User: Tor_Service_User
member of no group

[x] right to login as service
[x] deny local logon
[x] deny access from network to this computer
(don't no the correct terms because my windows is german)

comment:3 Changed 14 years ago by arma

Can you help modify the NSI bundle installer file to create the new user?
http://freehaven.net/~edmanm/torcp/download.html

It's probably fine just to modify the
http://freehaven.net/~edmanm/torcp/docs/bundle-alpha.nsi file since we'll
be releasing the final 0.1.1.x pretty soon I hope.

comment:4 Changed 14 years ago by cakruege

Why changeing the NSI?
"tor -install" and "tor -remove" have to be modified because they install/remove the tor service

comment:5 Changed 14 years ago by arma

Hm. You're right, we should do something about this.

But it makes me sad to put even more OS-specific stuff into the Tor executable.

Is there some reasonable way to have some external program (installer or controller
or something) handle it? For example, the Debian package makes its own user, but
that's not hard-coded inside Tor.

comment:6 Changed 14 years ago by cakruege

remove the -install and -remove option from tor and create a seperate config program (maybe includable in NSI, I don't know).
Here is an example:
http://www.codeproject.com/dotnet/ScriptedServiceInstall.asp

Direct writes to registry are possible too or WSH-scripts or .bat-files

comment:7 Changed 14 years ago by arma

Ok. There are zero Tor developers who use Windows currently.

If somebody wants to move forward with this (Carsten?), that
would be great. I agree that we need to have some way to turn
it into a service yet still be safe.

comment:8 Changed 14 years ago by cakruege

I'm no windows developer, too :-(

comment:9 Changed 14 years ago by qc

Maybe a seperate application which does the installation and removal of services. Doesn't have to be an installer or run from the Tor binary.

It could be invoked like "tor-win32-service -install" so that it could contain Windows specific code without "polluting" the codebase

comment:10 Changed 14 years ago by phobos

This is really two problems, 1) too many permissions, 2) installer/un-installer. In both cases, tor should run as _tor
just like it does on every other OS for which we have installers.

I hacked up someone else's script to do this, it doesn't work on XP Home for unknown reasons. Probably the domain requirement.

http://interloper.org/tmp/createuser.vbs

Any further enhancements would be great.

comment:11 Changed 14 years ago by richto

TOR when installed as a service also writes its config info to 'default user' which means that every new user account
created on th eserver gets a copy of the potentially sensitive TOR config and keys in its own profile.

If access to those files doesnt matter then the config should go into the 'all users' profile.

Otherwise you should use the environment variable %userprofile% to find the correct config location when running as a
service.

It should NEVER go into 'default user'.

comment:12 Changed 13 years ago by nickm

15:12 < edmanm> re bug 254, some say the tor service should run as

NetworkService, some sya it should run as LocalService, and
others say we should create a special user for the tor service
to run as.

15:14 < nickm> I think the latter approach is correct, but either of the first

two would probably be an improvement over status quo..

15:14 < edmanm> i lean towards the latter, since any services running as

NetworkService (e.g., IIS i believe) or LocalService (e.g.,
lots of other services), would have access to the tor server's
secret keys with the first two options.

15:14 < nickm> (unless I misunderstand)
15:15 < edmanm> creating a user correctly on the myriad of windowses that

support services is not easy, which is why we've been dragging
our feet on it.

15:15 < nickm> indeed...
15:15 < nickm> but I'd feel more comfortable if the fallback sucked less
15:15 < edmanm> but you're right, using one of the other two options would

probably be an improvement. (and simpler)

15:17 < nickm> ok. Since it doesn't look like user creation is forthcoming...

I think the right approach is to have --install take an optional
flag or two to say what to run as...

15:17 < nickm> and to have it default to something not completely insane.
15:17 < nickm> That way sensible admins and clever tools can make the user

manually and run install.

comment:13 Changed 13 years ago by nickm

Okay, I just did the approach suggested in the above chat: the default user
is NetworkService, and the default can be overridden with a --user argument.

Should I mark this bug as closed now, or shall I wait until a tool exists that
actually creates a Tor user for you when installing the service?

comment:14 Changed 13 years ago by cakruege

@Nick Mathewson:
NetworkService is WRONG!
LocalService is correct.

Please have a look at:
http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/sspgch02.mspx

The difference between local service and network service is that network services can authenticate in network with system privileges. Tor doesn't need this right!

LocalService has fewer rights than NetworkService and they are more than enough.

comment:15 Changed 13 years ago by nickm

Well, if I'm not only wrong, but I'm WRONG in all caps, I'd better fix it.

comment:16 Changed 13 years ago by nickm

Switched to LocalService, and added code to check whether the account exists, so we
can fall back to the previous default on Win2k installations with no LocalService.

Again, still no idea if it compiles, let alone works.

comment:17 Changed 13 years ago by nickm

Seems to compile and work in 0.1.2.7-alpha. The LookupAccountName code kept crashing, and had
to be disabled; we need to fix that before 0.1.2.x-final. In any case, we now install as LocalService
by default, and allow the installing admin to set a user/password pair when installing Tor, so
I'm going to mark this as Implemented. Please re-open this bug if anything is broken or otherwise
doens't work.

comment:18 Changed 13 years ago by nickm

flyspray2trac: bug closed.
Implemented in 0.1.2.7-alpha.

comment:19 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.