CODEWITHSUNDEEP
windows-serviceswix
user3071170
user3071170

Reputation: 485

How to make WiX install a service in the context of a newly created user

I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:

  1. Start the msi in the per-machine context.
  2. During the client stage of the installation ask for the user name and password.
  3. During the server stage of the installation:
    a) create the user
    b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
    c) change back to the admin context and install and configure the service to be run under the user account

I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?

I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.

Upvotes: 0

Views: 768

Answers (2)

Sean Hall
Sean Hall

Reputation: 7878

I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:

<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>

It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.

Upvotes: 1

PhilDW
PhilDW

Reputation: 20780

The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.

It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.

Upvotes: 1

Related Questions