One of my favorite comedians is Frank Caliendo, an impersonator who does several well-known celebrities including Morgan Freeman, Al Pacino, John Madden, Charles Barkley, and football coach John Gruden. If you haven’t seen him, check him out on YouTube—he’s hilarious. My favorite one is when he impersonates John Gruden, wearing an oversize Super Bowl diamond ring, while meeting the real Gruden face-to-face, and fake Gruden comments that they’ve “broken the space-time continuum, man!” You may even learn what “spider 2 Y banana” is.

In entertainment, impersonators are funny, but in terms of security in software, it’s no laughing matter and could leave your system vulnerable. Prior to version 11, xfServer and xfServerPlus always started up their services as system user (on Windows it’s the LocalSystem user and on Unix it’s root). Then, when a connection was made, xfServer/xfServerPlus impersonated the specified user account and launched the dbs process as that user. So where’s the security hole? Typically, the system user has wide privileges across the entire system, so if anyone could hack into those services, they could possibly gain access to files accessible by the system user—files that you thought were protected.

Synergex is always looking for ways to increase security in our products, and we were happy to satisfy a couple of user ideas in this area. One user had a requirement to run these services as a specific user with restricted access, not the system user. Another user recommended we run as one of a couple of built-in user accounts with restricted access on Windows. Both of these were great ideas, which could benefit many of our customers, so we implemented them.

When you upgrade to version 11, if you’ve previously configured xfServer or xfServerPlus services, they’ll continue to run as before. To get the service to run as user on Windows, you’ll need to reregister the service and give it the username and password of the user you wish it to run as. You can tell whether the service is registered to run as user by checking SynConfig. For xfServer, if you’re not registered to run as user, the “Run as user” radio button will not be selected. For xfServerPlus, if you’re registered the old pre-version 11 way, you’ll see a “Please re-register to run as user” message underneath the password field. Once you’ve re-registered and applied the change, when the service is restarted it will run as the given user. Note that the minimum requirement for the user account on Windows is that it have the “log on as a service” privilege, which can be set in the Local Security Policy app. Most importantly, the user will need privileges to access any files or directories the service accesses – and it’s a good idea, for security purposes, to give only those privileges.

On Windows, you can confirm that the service is registered to run as user if you open the Services app and look at the “Log On” tab of that service. It will show the account it’s running against. Below is an example of xfServer running as local “mytest” user.

On Unix, run as user is controlled through effective user mode. Currently, rsynd is distributed to always run as root. If you always want to run xfServer/xfServerPlus as a particular user, regardless of who starts it, such as some startup script, change the owner of rsynd to that user and do setuid u+s on it. If you only want xfServer/xfServerPlus to run as the user who started it, you only need to change the owner on rsynd and then start it up using the desired account (you don’t need +s bit set). Just like on Windows, the user account must have privileges to access any files or directories the service accesses.

The second user-requested change was to be able to specify two special, restricted accounts for running xfServer/xfServerPlus services on Windows: NT Authority\LocalService and NT Authority\NetworkService. Each of these has different restricted privileges, so check out the Microsoft documentation to see if they’ll work for you. The big difference between these two accounts and LocalSystem is that LocalSystem is part of the system’s Administrator group, whereas these two are part of the Users group, which is much more restrictive. When entering either of these, you don’t need to enter a password. It is preferable to set up a specific user account to run the service and only give that account the exact privileges that are needed for the service; however, if these special accounts meet your security needs, then use them and avoid the extra maintenance of another user account.

Another related change to increase security on Windows is that we don’t store the password of the run as user account. Instead, we use it to register the service and then we let Windows manage it from then on. This means that anytime you make a change to the service in SynConfig, you’ll need to re-enter the password, except for the two special Windows accounts mentioned above.

If you haven’t done so already, download and install version 11 of Synergy and try out the new run as user security feature for xfServer and xfServerPlus. We listen to your ideas and give priority to those involving improved security, so keep them coming. We encourage you to always look at improving security in your own applications with every release of your product. Even small, incremental changes make a big difference over time. If you don’t update security, eventually some nefarious hacker could break more than the space-time continuum, man!