I personally think it should be one installation package with the option to install as a service.
The only use case I’ve used so far is for a company with circa. 18 devices, one device is a very powerful dedicated server hosted in a data centre, the others are mainly Windows 7/8.1 devices with 1 MacAir. I don’t want to have the trouble of installing for each user on each device.
I’m heavily against services in a user context.
In our department we have about 10 machines, 4 of them are used by different people and need access to files that are best synchronized to local files. If two users decide to install their shares as service they will not only sync the same data twice (which is not the problem) but they will do it simultaneously, hidden behind services that might not be visible to the user itself, but only to machine administrators.
If a user log’s in, they are allowed to run whatever they want in their own context, but as soon as they log off, everything related to them needs to shut down or the machine might become unresponsive.
On the other side, if we want to host a server, one service is enough. Maybe a slimmer or CLI interface would help, but I do not see a scenario where multiple services would help in any way (except in SASS enviroment).
Looks like the discussion’s turning from “Service or start-on-login” to “One installer for both service and per-user start-on-login, or two separate installers”?
This question is more nuanced. My personal worry is that starting Syncthing as a service has severe security implications, and so we should only let people who know what they’re doing, and who know for sure that what they need is a service (as opposed to “Oh, that looks neat” or “I dunno, maybe this one?”) install Syncthing as a service. I doubt whether presenting the two options side-by-side in the same installer achieves this. Other opinions welcome!
The most effort / best thing to do would be to create a new user account for the service, and make the service run as that, and then make the user explicitly grant file access to those folders they want to sync… That’s well beyond what I can do in NSIS without taking weeks over it though =)
I still think the idea of a possible attack are very small, even if said malware got into the share to delete all files, the user would need to execute it first. Once that has been executed, surely it would have the privileges anyway or am I missing something?
Unless the user makes a share under system32 which would allow anyone with the same share to delete it anyway.
I don’t see how
Grants any merit, how will the malware be executed in the first place? Syncthing splitting it up into blocks sure wouldn’t do that it would be the USER executing the file opening the system up with THEIR privileges.
Am I wrong?
I get that a buffer overflow is another option but Golang isn’t affected by buffer overflow exploits so this whole discussion seems rather pointless.
https://talks.golang.org/2010/go_talk-20100323.html (slide 17)
Garbage Collected Go is also a safer language: Pointers but no pointer arithmetic No dangling pointers Variables are zero-initialized Array access is bounds-checked No buffer overflow exploits
The point is that if a user executes a malicious file, that file runs with the user’s permissions. It can only change things the user has permission to change.
But… If Syncthing is running as a local admin, and doesn’t have a GUI password set up, any process can talk to Syncthing. Even the most unprivileged process can open a connection on port 8080 and talk to its REST API. It can ask Syncthing to set up a folder anywhere (since Syncthing, running as local admin, has permission to do anything), and it can then ask Syncthing - very nicely, and without needing to overflow any buffers - to read or write any file in that folder.
There are several lines of defence against malware. The first line is the user - trusting your user not to download/run a file which looks legit but isn’t. Users, in general, are notoriously bad at doing this, especially the less computer literate. Browser vulnerabilities also let malicious people run processes on your computer without your consent.
We try and teach our users to behave here, but we don’t trust them to.
The next line of defence is user permissions. Since Vista, user accounts of been fairly unprivileged by default, with a UAC prompt required to elevate those permissions (Linux has taken this approach since the dawn of time). If I can get malware onto someone’s computer - and this happens all the time, you can’t argue that it isn’t a risk - then I can only run processes with the same privileges as that user. I can delete their files (cryptolocker), I can show adware all the time, but I can’t install a keylogger, disable the antivirus, make modifications to existing programs, or alter windows. Well, I can try, but they’ll get that pesky UAC prompt and know something’s up.
… or not. If I have a look around and see that Syncthing is running as a local admin, and without a GUI password, then, as disucussed, I can modify any file I like, anywhere I like. It doesn’t take a big imagination to figure out how I can use that to get a process running with local admin privileges.
At this point you’ve lost. I’ve got full admin control of your computer. I’ve disabled your anti-virus, and installed that keylogger. I’ve got your bank details.
If you’re trying to argue that you should give all of your users local admin privileges, there are plenty of articles out there explaining why this is a Very Bad Idea. Letting Syncthing run as a local admin, without a GUI password, is tantamount to the same.
Not without the API key you can’t and Syncthing doesn’t allow you to add a share this way.
Actually, now I’m getting a bit scared. If I merely trick you into visiting my webpage, some Javascript from my page running in a browser can get the config from localhost:8080, get the API key, modify the config to add the folder containing your NT SAM database (or where ever the Windows passwords are kept these days) and share it with me, post the config back, and reset your Syncthing.
Exactly. Unless you’ve configured a GUI password (which is the caveat I’ve always stated), anything that can open a connection on localhost:8080 can do whatever the hell it likes to Syncthing.
And of course you can add a share this way. How do you think the GUI works? Just edit the config, and post it back.
Relevant:
The same origin policy should prevent this attack, I think?
You have a very good point in that issue, see my comment.
I agree with @calmh - there’s no vulnerability inherent in the REST interface. The vulnerability is that you’ve got a service running as local admin which is not password-protected.
I think there’s a case in point here. It took me 2 threads and 2 other people chipping in to convince you that there’s a security risk here. You were very receptive and patient (and I’m grateful for that): if you weren’t, I’d have never managed to make my point.
Now, try carrying out the same knowledge transfer to every newbie who wants to install Syncthing. Are you going to be able to explain all of the risks, implications, and security considerations to someone who just wants to install the damn thing? Particularly, as you don’t have two-way dialogue or a way of holding their attention. No, you’re not.
Service installation is possible, fine, and works well, provided that the person doing it understands the implications of what they’re doing (and the Windows security model). I don’t trust the average user to do this. Hell, I don’t trust 99% of people to handle Windows permissions correctly. I certainly don’t trust myself here.
It is for this reason that I’m so strongly against making installation-as-a-service something that’s easy to do for the casual user. By all means provide an installer, but hide it behind a page of explanation, and don’t include it in the safer, user-level installer.
I guess we could have a Install as a service as some hidden advanced option in the installer with the explanation of threat, and an option to setup UI creds there and then (perhaps even mandatory). Also, how does it work, if SyncTrayzor implements service controls, does the user still get a tray icon even though the service runs under a different account?
It would also be cool to have an unattended installer, both for a user and for a service (again, with creds provided or something), so that it could be baked in into the standard OS image.
My preferred approach would be:
Something about running a file synchronization program as local admin makes me very nervous indeed, even if there is a password on it. It makes Syncthing a very tasty program to find an exploit in, and you don’t want to find yourself between someone with a lot of skill and time on their hands, and their money.
A decent prompt saying “which user do you want to run the Syncthing service as?”, and not making it obvious that Local Admin is an option (although allowing it if the person really knows what they want) might be sensible. That way people are prompted towards installing the Syncthing services as either an existing user, towards creating a new dedicated user account.
If you wanted to integrate Syncthing into a tray utility, that’s a little bit of work. You’d need to write a wrapper for Syncthing (replacing NSSM) which would be responsible for starting / restarting / stopping it, managing the API key and host address, and for capturing its STDOUT. The tray utility would then communicate with the wrapper instead of managing the process directly.
Another thought: if Syncthing is running system-wide, do you want to give individual users access to it? That depends on whether you want users to muck about with the config, just be able to see the results of the synchronization, or not care at all (as in the case of the guy who was using Syncthing to transfer database backups). In the latter two cases, a tray utility would be useless.
Syncthing is inherently a single user thing at the moment. Running it as a privileged user is not tested nor recommended. Running it as a specific service user on OS:es where that makes sense sounds fine, but that won’t make it multiuser.
It sounds as if a Windows service would be better off running as the intended end user account, and/or possibly the installer should enforce setting up authentication as part of the install process?
I like the idea of asking the user which user to run the service as during installation.
I’m not a security expert, but I might be paranoid. Suggestions/ideas:
Service if it’s a pure implementation of the entire protocol spec , with the intention of running on Windows Server 2008 or similar type instance. Like a build for an Amazon EC2 Windows instance should run as LocalService/LocalSystem , so it would continue to start across reboots (without the need for human intervention).
I’d think it should be start-on-login for ‘end user’ type code (probably a majority of users), as their machines will usually only be on when they are logged in. In other words, few ‘end users’ will leave their laptop open at the Windows login screen, yet still expect Syncthing to be running in the background.
Most end-users I think would expect that for Syncthing to work, they’d need to be (A) powered on , and (B) logged in for the file sharing to work.
+1 for the option to setup a new user as part of the install process and maybe this could also make the Default share also point into their %HomePath%?
I really don’t like the idea of having to install Syncthing for each user on each machine and setup several ID’s for each one as I’m unsure of how Syncthing will react when I just copy the same certificates over and then that user logs in on 2 machines at the same time…